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 17:07:38
Message-ID: CA+TgmoYc8_kCrq_TpGy83TkV4dRjPHC_wpbRBFWMzSuNHyiy0A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jan 2, 2025 at 4:41 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I'm not seeing where there's a correctness issue here? The parser
> is charged with assigning aliases to RTEs that lack one, and with
> this patch that's still true. It's just assigning a different alias
> than it did before. There is no question of whether the alias can
> "leak" out of the implicit sub-select; it cannot, by SQL's scoping
> rules. We have to avoid changing anything if there are clauses
> inside the implicit sub-select that could reference the old choice
> of alias, but the patch does that.

Hmm, maybe you're right. I think when I looked at this initially, I
thought the problem had to do with conflating the plan choice, but
looking at it again, it looks like more of a
using-the-alias-before-it's-defined problem, which I guess is easy
enough to fix without much action at a distance.

> (Or we could decide to simplify
> things at the cost of breaking such SQL code, since there probably
> is none in the field. It's still not clear to me which choice is
> better.)

This part I don't understand.

--
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 17:35:54 Re: Non-text mode for pg_dumpall
Previous Message Fujii Masao 2025-01-06 17:04:20 Re: Enhancing Memory Context Statistics Reporting