From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: SELECT INTO deprecation |
Date: | 2020-12-09 20:48:54 |
Message-ID: | 737048bf-de51-3fd4-bbcc-89f6d2bd2c4f@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
Attachment | Content-Type | Size |
---|---|---|
v2-0001-Remove-gratuitous-uses-of-deprecated-SELECT-INTO.patch | text/plain | 11.6 KB |
v2-0002-doc-Clarify-status-of-SELECT-INTO-on-reference-pa.patch | text/plain | 1.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2020-12-09 20:53:40 | Re: Hybrid Hash/Nested Loop joins and caching results from subplans |
Previous Message | Robert Haas | 2020-12-09 20:39:40 | Re: libpq compression |