Re: SELECT INTO deprecation - Mailing list pgsql-hackers

From Tom Lane
Subject Re: SELECT INTO deprecation
Date
Msg-id 1723856.1607009655@sss.pgh.pa.us
Whole thread Raw
In response to Re: SELECT INTO deprecation  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Responses Re: SELECT INTO deprecation
List 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 by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: PoC/WIP: Extended statistics on expressions
Next
From: Pavel Borisov
Date:
Subject: Re: Corner-case bug in pg_rewind