2017-08-24 11:46 GMT+02:00 Vincenzo Romano <vincenzo.romano@xxxxxxxxxxx>:
2017-08-24 11:04 GMT+02:00 Pavel Stehule <pavel.stehule@xxxxxxxxx>:
>
>
> 2017-08-24 9:11 GMT+02:00 Vincenzo Romano <vincenzo.romano@xxxxxxxxxxx>:
>>
>> 2017-08-24 3:08 GMT+02:00 Tom Lane <tgl@xxxxxxxxxxxxx>:
>> > "David G. Johnston" <david.g.johnston@xxxxxxxxx> writes:
>> >> I'm wondering if there is anything technical preventing someone from
>> >> making:
>> >
>> >> DROP TEMP TABLE tablename;
>> >
>> > There is no great need for that because you can get the semantics you're
>> > asking for with "DROP TABLE pg_temp.tablename".
>> >
>> > regards, tom lane
>>
>> This sounds like another syntax inconsistency/asymmetry.
>>
>> ALTER TABLE pg_temp.tablename ... is OK.
>> ALTER TEMP TABLE tablename ... is NOT OK.
>>
>> CREATE TEMP TABLE tablename ... is OK.
>> CREATE TABLE pg_temp.tablename ... is OK.
>>
>> DROP TABLE pg_temp.tablename ... is OK.
>> DROP TEMP TABLE tablename ... is NOT OK.
>>
>> Unless the standard explicitly forbids it, why not supporting both
>> syntaxes in all commands using the TABLE predicate?
>> Those are semantically equivalent. Aren't they?
>
>
> It can be issue when somebody will do port from PostgreSQL to any other
> databases.
Postgres is already creating issues to people porting DBs away from it
as it sports a number of extensions.
So this does not sounds like a good argument.
I am thinking, and it is my opinion, nothing more, so Postgres should to introduce proprietary syntax only when there are not any possibility and there are not some similar in ANSI or Oracle, DB2 or MSSQL.
> There should be stronger reason for introduction possible NON
> ANSI SQL feature than syntactic sugar.
Once you accept that Postgres is already extending the standard, I
would focus on syntax consistency and symmetry as a yet-another-extra
value from Postgres.
Moreover, "DROP TEMP TABLE..." would make it clear and explicit that
the table is temporary.
And it would thus "protect the programmer from typos and errors"
(intentional tongue-in-cheek).
If we disable DROP TABLE on temporary tables, then your arguments are 100% valid, but if we don't do it, then DROP TEMP TABLE is just syntactic sugar
Regards
Pavel
