Re: SELECT INTO deprecation
От | Jan Wieck |
---|---|
Тема | Re: SELECT INTO deprecation |
Дата | |
Msg-id | 7a3a1fd1-3111-229a-5a91-195bc74c70c3@wi3ck.info обсуждение исходный текст |
Ответ на | Re: SELECT INTO deprecation (Bruce Momjian <bruce@momjian.us>) |
Список | pgsql-hackers |
On 12/15/20 5:13 PM, Bruce Momjian wrote: > 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. > If memory serves the INTO syntax is a result from the first incarnation of PL/pgSQL being based on the Oracle PL/SQL syntax. I think it has been there from the very beginning, which makes it likely that by now a lot of migrants are using it in rather old code. I don't think it should be our business to throw wrenches into their existing applications. Regards, Jan -- Jan Wieck Principle Database Engineer Amazon Web Services
В списке pgsql-hackers по дате отправления: