On Thu, Jan 2, 2025 at 5:11 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Okay, but then we still have the problem of how to ensure that in > a query that has inline'd some views. I think solving the sort of > I-want-to-reference-this problem you describe would require > that we unique-ify the aliases in the rewriter, just after it > finishes incorporating any views. We could do that, but it seems > like a lot of cycles to expend on something that would be pointless > in the typical case where nobody ever looks at the aliases later.
Right, plus if you care about function-inlining or inheritance-expansion, those happen even later, at planning time. > > My original > > proposal of getting rid of system-generated fake names isn't > > necessary, because you very helpfully pointed out that I can look at > > whether RTE->alias->aliasname exists to figure that out. > > Actually, I noticed that we are failing to honor that in the places > where we inject "*SELECT*" and "*SELECT* %d" names, because that > code puts those names into RTE->alias not only RTE->eref. > I experimented with the attached patch to not do that anymore, > which is sort of a subset of what you did but just focused on > not lying about what's generated versus user-written. We could > alternatively keep the current generated names by extending > addRangeTableEntryForSubquery's API so that alias and generated eref > are passed separately. (I didn't look to see if anyplace else > is messing up this distinction similarly.) Hmm, I definitely like not lying about what is generated vs. what is user-written. I don't have a strong opinion right now on the best way of accomplishing that. -- Robert Haas EDB: http://www.enterprisedb.com
