Re: SELECT INTO deprecation
Bruce Momjian <bruce@momjian.us>
From: Bruce Momjian <bruce@momjian.us>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Michael Paquier <michael@paquier.xyz>, Stephen Frost <sfrost@snowman.net>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2020-12-15T22:13:25Z
Lists: pgsql-hackers
On Wed, Dec 9, 2020 at 09:48:54PM +0100, Peter Eisentraut wrote: > On 2020-12-03 20:26, Peter Eisentraut wrote: > > On 2020-12-03 16:34, Tom Lane wrote: > > > 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. > > > > On sqlfiddle.com, this works: > > > > select a into t3 from t1 union select a from t2; > > > > but this gets an error: > > > > select a from t1 union select a into t4 from t2; > > > > SELECT INTO must be the first query in a statement containing a UNION, > > INTERSECT or EXCEPT operator. > > So, with that in mind, here is an alternative proposal that points out that > SELECT INTO has some use for compatibility. Do we really want to carry around confusing syntax for compatibility? I doubt we would ever add INTO now, even for compatibility. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee
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