Re: Improving default column names/aliases of subscript text expressions

Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> writes:
> On Mon, 16 Dec 2024 at 21:09, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> However, after thinking a little longer I seem to recall that we've
>> previously looked into the idea of deriving the default aliases from
>> the post-parse-analysis tree. We gave up because there were too many
>> cases where the behavior would change, or at least it looked unduly
>> painful to prevent that.

> I think you remember wrong, or things have changed drastically since.
> Because it only required fairly minimal changes to base the column
> name on the transformed expression, see the attached POC.

Oh, well if you're willing to cheat like that, sure ;-). I was
speaking of replacing the existing logic with something that looked
only at the post-analysis tree.

I dunno, this is so obviously a single-purpose kluge that it's hard
to call it anything but a kluge. I'm not convinced this is better
than writing out "SELECT data['a'] AS a, data['b'] AS b, ...".

In particular, it seems like what's going on here is that you
are using extensible subscripting because that's what's available,
but what you really wish you had is extensible field selection.
If you could write "SELECT (data).a, (data).b, ..." then the
existing FigureColname heuristics would do what you want already.
I know we kicked that idea around a little in the past, but
nobody has looked into it seriously.

regards, tom lane