Re: magical eref alias names

On Thu, Jan 2, 2025 at 5:11 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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