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
