Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kpIZa-0008Mr-0S for pgsql-hackers@arkaria.postgresql.org; Tue, 15 Dec 2020 22:13:34 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kpIZX-0003F2-Bk for pgsql-hackers@arkaria.postgresql.org; Tue, 15 Dec 2020 22:13:31 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kpIZX-0003Ev-5G for pgsql-hackers@lists.postgresql.org; Tue, 15 Dec 2020 22:13:31 +0000 Received: from momjian.us ([72.94.173.45]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kpIZU-0002ko-TL for pgsql-hackers@postgresql.org; Tue, 15 Dec 2020 22:13:30 +0000 Received: from bruce by momjian.us with local (Exim 4.92) (envelope-from ) id 1kpIZR-0006m1-8f; Tue, 15 Dec 2020 17:13:25 -0500 Date: Tue, 15 Dec 2020 17:13:25 -0500 From: Bruce Momjian To: Peter Eisentraut Cc: Tom Lane , Michael Paquier , Stephen Frost , pgsql-hackers Subject: Re: SELECT INTO deprecation Message-ID: <20201215221325.GA14807@momjian.us> References: <96dc0df3-e13a-a85d-d045-d6e2c85218da@enterprisedb.com> <20201202175836.GX16415@tamriel.snowman.net> <1672926.1606941346@sss.pgh.pa.us> <8e05fc79-abca-dd3f-4d48-8aaae9525a8f@enterprisedb.com> <1723856.1607009655@sss.pgh.pa.us> <737048bf-de51-3fd4-bbcc-89f6d2bd2c4f@enterprisedb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <737048bf-de51-3fd4-bbcc-89f6d2bd2c4f@enterprisedb.com> User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk 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 https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee