Re: magical eref alias names

On Thu, Nov 7, 2024 at 4:38 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > What I'm unhappy about is not being able to tell the difference
> > between a name that was invented by or at least meaningful to the user
> > and one that isn't.
>
> You can already tell that, by looking to see whether
> RTE->alias->aliasname exists. eref is meant to be the resolved
> name-to-use not the user's original input.

Hmm, OK, that's useful. But I guess I'm still puzzled about the theory
here. A name like *VALUES* doesn't seem like it was created with the
idea of referring to it from some other part of your query. I do take
your point that it works and somebody's probably relying on it, but I
don't think you'd pick a name that requires quoting if you were trying
to make it easy to use that name in the query. You might possibly also
try to generate names that are easy for users to guess, and distinct.
Since none of that was done, it seems like it was just intended for
display. But EXPLAIN already has its own logic to decide on what names
it will display in the output, which may be different from anything
that was entered by the user or invented by the parser
(set_rtable_names()).

So the whole thing just seems like a really strange system. I find it
hard to avoid the conclusion that it's just a historical accident --
somebody did something 20 or 30 years ago to make it all work, before
we had all the infrastructure that we do today, and then none of those
decisions ever got revisited due either to inertia or backward
compatibility concerns. Do you see it differently?

> The trick there is to keep them predictable, because as I mentioned in
> my previous response, there may be people depending on knowing what
> name will be assigned. We're working with a ton of history here,
> and I'm not really convinced that change will be change for the
> better.

Yeah, I don't really want to be the one to break somebody's query that
explicitly references "*VALUES*" or whatever. At least not without a
better reason than I currently have. If this were just a display
artifact I think finding some way to clean it up would be pretty
worthwhile, but I would need a better reason to break working SQL.

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