On Thu, Jan 2, 2025 at 4:41 PM Tom Lane <tgl@sss.pgh.pa.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
