Re: SELECT INTO deprecation

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: SELECT INTO deprecation
Дата
Msg-id 1723856.1607009655@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: SELECT INTO deprecation  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Ответы Re: SELECT INTO deprecation  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Список pgsql-hackers
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> Interesting.  This appears to be the case.  SQL Server uses SELECT INTO 
> to create a table, and does not appear to have CREATE TABLE AS.
> So maybe we should keep it, but adjust the documentation to point out 
> this use case.

That argument makes sense, but only if our version is a drop-in
replacement for SQL Server's version: if people have to adjust their
commands anyway in corner cases, we're not doing them any big favor.
So: are the syntax and semantics really a match?  Do we have feature
parity?

As I recall, a whole lot of the pain we have with INTO has to do
with the semantics we've chosen for INTO in a set-operation nest.
We think you can write something like

   SELECT ... INTO foo FROM ... UNION SELECT ... FROM ...

but we insist on the INTO being in the first component SELECT.
I'd like to know exactly how much of that messiness is shared
by SQL Server.

(FWIW, I think the fact that SELECT INTO means something entirely
different in plpgsql is a good reason for killing off one version
or the other.  As things stand, it's mighty confusing.)

            regards, tom lane



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

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: PoC/WIP: Extended statistics on expressions
Следующее
От: Pavel Borisov
Дата:
Сообщение: Re: Corner-case bug in pg_rewind