Re: SELECT INTO deprecation
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: Michael Paquier <michael@paquier.xyz>, Stephen Frost <sfrost@snowman.net>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2020-12-03T15:34:15Z
Lists: 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
Commits
-
doc: Clarify status of SELECT INTO on reference page
- 65330622441d 14.0 landed
-
Remove gratuitous uses of deprecated SELECT INTO
- b034ef9b376d 14.0 landed