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
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 |