Re: Alias of VALUES RTE in explain plan
От | Andrei Lepikhov |
---|---|
Тема | Re: Alias of VALUES RTE in explain plan |
Дата | |
Msg-id | 3f724eef-cbfd-4cb3-ac74-16e3a478656d@gmail.com обсуждение исходный текст |
Ответ на | Re: Alias of VALUES RTE in explain plan (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 10/30/24 00:19, Tom Lane wrote: > Andrei Lepikhov <lepihov@gmail.com> writes: >> -- New behavior >> EXPLAIN (COSTS OFF, VERBOSE) >> SELECT * FROM (VALUES (4),(2),(3),(1) ORDER BY t1.x LIMIT 2) AS t1(x); >> SELECT * FROM (VALUES (4),(2),(3),(1) ORDER BY t1.x LIMIT 2) AS t1(x); > > After taking a closer look at that, yeah it's new behavior, and > I'm not sure we want to change it. (The existing behavior is that > you'd have to write 'column1' or '"*VALUES*".column1' in the > subquery's ORDER BY.) > > This example also violates my argument that the user thinks they > are attaching the alias directly to VALUES. So what I now think > is that we ought to tweak the patch so that the parent alias is > pushed down only when the subquery contains just VALUES, no other > clauses. Per a look at the grammar, ORDER BY, LIMIT, and FOR > UPDATE could conceivably appear alongside VALUES; although > FOR UPDATE would draw "FOR UPDATE cannot be applied to VALUES", > so maybe we needn't worry about it. > > Thoughts? You have written before that a VALUES alias should be a special case because it's a 'natural thing'. And I buy it. So, it looks natural to use this alias everywhere in the query without restrictions. That's why I provided examples in my previous email to check that it is a full replacement for the '"*VALUES*".columnN'. -- regards, Andrei Lepikhov
В списке pgsql-hackers по дате отправления: