Re: magical eref alias names

On 11/8/24 20:33, Robert Haas wrote:
> On Thu, Nov 7, 2024 at 4:38 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.
Thanks for this topic! Having run into this years ago, I was confused by 
eref and alias fields.
I frequently use eref during debugging. Also, knowing the naming 
convention makes it much easier to resolve issues with only an 
explanation when the user can't provide any other information. I wonder 
if other people who work with EXPLAIN a lot already have some sort of 
habit here.
I agree that the naming convention can float, but please let it be 
stable and predictable.
Also, I'm not sure how other extension developers operate, but in a 
handful of mine, I use the fact that eref always contains a name - the 
relational model requires a name for each (even intermediate) table and 
column, doesn't it?
Also, do not forget that these names can be used in pg_hint_plan hints - 
one more reason to make it stable.

-- 
regards, Andrei Lepikhov