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

On Mon, 16 Dec 2024 at 21:09, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Hm. If we made this behavior type-specific then you could have what
> you want without having to break any existing expectations at all.

Yeah, I agree that's definitely the safest. So, that's basically
option 2 I described in my first email, right?

Then once implemented, we might choose that in a separate patch we
want to use that hook for the json subscript.

> 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. For instance, something that looks like a
> function call in the raw tree could parse to half a dozen different
> kinds of nodes. So I'm not sure how we get there from here.

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. This doesn't
implement any hooks yet, but I put some comments where they could be
added. This gets the explicit cast support for free btw, because the
transform step removes that for the text type.