Re: magical eref alias names

On Wed, Jul 23, 2025 at 5:35 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> [ returning to this thread now that v19 is open for business ]

Thanks for your attention to this, and sorry for the slow response.

> I think the case this is worried about is that if you have a parent
> table t(a,b,c), and the query writes say "t as t1(x)", then t's column
> "a" will be labeled "x" by EXPLAIN and we want the child's column "a"
> to similarly be labeled "x".

OK, but I don't quite see how that would go wrong. My proposal was to
assign eref to eref and alias to alias. If the parent has no alias,
then the child would also have no alias, but the eref would match. If
the parent does have an alias, then the child would end up with an
alias matching the parent, which would presumably take precedence over
the eref that would also match the parent. For what we're doing now to
be necessary, there must be something in ruleutils.c that either needs
the eref and alias of a child to match, or needs the eref of a child
to match the alias of the parent, unless I'm missing something. There
might well be such a thing, I'm just not sure what it is.

> We could certainly do something a little different than what the code
> is doing, such as "if the parent does have a user-written alias, use
> parentrte->alias->aliasname not parentrte->eref->aliasname for the
> childrte->alias->aliasname".  I'm not sure it's worth bothering with
> that, though.

I don't have a clear opinion on this. I don't understand well enough
what's being done here. I don't think not doing this is going to cause
my development plans any immediate problems, but some of this stuff is
quite fiddly and hard to understand.

> I noticed that the patchset was failing in cfbot because we've since
> grown another regression test case whose output is affected by 0002.
> So here's a v3 that incorporates that additional change.  I did a
> little bit of wordsmithing on the commit messages too, but the code
> changes are identical to v2.

Thanks. I committed these today, after editing the commit message for
0003 a bit more.

--
Robert Haas
EDB: http://www.enterprisedb.com