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