Re: Alias of VALUES RTE in explain plan

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Andrei Lepikhov <lepihov(at)gmail(dot)com>, Yasir <yasir(dot)hussain(dot)shah(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Alias of VALUES RTE in explain plan
Date: 2025-01-06 21:15:21
Message-ID: CA+TgmoZE_+WcEkYUdhSuVzV1M=kV7kEbBHCkrHvQK04hQFcR3Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jan 6, 2025 at 3:45 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> SELECT ... FROM (VALUES (...) ORDER BY a) v(a,b,c)
>
> If it'd been like that all along, nobody would blink at it I think,
> even though you could argue that it's action-at-a-distance to let
> an outer alias affect what happens inside the implicit subquery.

To be honest, that pushdown feels really uncomfortable to me. To me,
the natural syntax for associating an alias with a VALUES clause would
be something like "VALUES (...) myalias" or, if you also wanted column
aliasing, "VALUES (...) myalias(a,b,c)". That would feel just like
what we allow when aliasing a table or a function reference. But to
not allow that syntax but then allow the outer alias to propagate
inward in this one case seems quite strange to me. It doesn't really
seem evil in a vacuum, but it seems non-orthogonal with what we do
everywhere else, because aliases in SQL generally flow outward, not
inward.

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2025-01-06 21:27:18 Re: Statistics Import and Export
Previous Message Guillaume Lelarge 2025-01-06 21:08:36 Re: Log connection establishment timings