Re: [GENERAL] DROP [TEMP] TABLE syntax, as reason why not?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [GENERAL] DROP [TEMP] TABLE syntax, as reason why not?
Дата
Msg-id 30579.1503575812@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [GENERAL] DROP [TEMP] TABLE syntax, as reason why not?  (Francisco Olarte <folarte@peoplecall.com>)
Список pgsql-general
Francisco Olarte <folarte@peoplecall.com> writes:
> On Thu, Aug 24, 2017 at 12:48 PM, Vincenzo Romano
> <vincenzo.romano@notorand.it> wrote:
>> 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.

> Valid arguments, but those extensions are NOT free to develop, test
> and maintain.

I think the more important point is the one already alluded to upthread:
it doesn't make any sense to invent DROP TEMP TABLE unless we're willing
to follow through on all the logical consequences of treating temp tables
as a distinct kind of object, the way that e.g. views and materialized
views are considered distinct.  So we'd need ALTER TEMP TABLE,
TRUNCATE TEMP TABLE, yadda yadda, and we'd need to forbid applying the
wrong type of command to regular vs. temp tables.  The first of those
makes this a considerably less trivial patch, and the second one would
be unlikely to get accepted because of the compatibility break for
existing applications.  But if you don't do the second one, then what
you've mostly accomplished is to introduce more irregularity rather
than remove some.

Another issue is that regular and temp tables aren't very different
kinds of objects, the way that views and matviews are.  I think it's
really a rather unfortunate choice on the part of the SQL committee to
have denoted temp tables by putting the modifier word right there, rather
than attaching it as an option somewhere later in the command.  We should
not let that syntax accident drive what we consider reasonable semantics
to be.

(Also, once you've done all that, do you want to also do it for UNLOGGED
tables?)

            regards, tom lane


В списке pgsql-general по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [GENERAL] 'value too long' and before insert/update trigger
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [GENERAL] Explain analyse and toasted data.