2017-08-24 12:06 GMT+02:00 Pavel Stehule <pavel.stehule@gmail.com>:
>
>
> 2017-08-24 11:46 GMT+02:00 Vincenzo Romano <vincenzo.romano@notorand.it>:
>>
>> 2017-08-24 11:04 GMT+02:00 Pavel Stehule <pavel.stehule@gmail.com>:
>> >
>> >
>> > 2017-08-24 9:11 GMT+02:00 Vincenzo Romano <vincenzo.romano@notorand.it>:
>> >>
>> >> 2017-08-24 3:08 GMT+02:00 Tom Lane <tgl@sss.pgh.pa.us>:
>> >> > "David G. Johnston" <david.g.johnston@gmail.com> 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.
Mine are also opinions.
>> > 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
Isn't a CHOICE for better syntax enough?
Aren't symmetry and consistency valuable arguments?
Syntactic sugar is not evil on its own.
It can help people writing code that can be better understood.
And it would still be up to the programmer to choose.
--
Vincenzo Romano - NotOrAnd.IT
Information Technologies
--
NON QVIETIS MARIBVS NAVTA PERITVS
