Re: Proposition for autoname columns

"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> The query rewriter would only rewrite these expressions and provide an
> expression-related explicit alias clause if the expression is a single
> operator (same as single function today) and the right-hand side of the
> operator is a constant (meaning the constant is a reasonable representation
> of every output value that is going to appear in the result column).

I haven't been paying too close attention to this thread, but it seems
like there is a lot of misapprehension here about how this could
reasonably be implemented. There is zero (not epsilon, but zero)
chance of changing column aliases at rewrite time. Those have to be
assigned in the parser, else we will not understand how to resolve
references to sub-select output columns. Specifically it has to happen
in FigureColname(), which means that resolving non-constant arguments
to constants isn't terribly practical.

Actually, since FigureColname() works on the raw parse tree, I'm not
even sure how you could make this happen in that context, unless you're
willing to say that "j ->> 'x'" resolves as "x" just based on the name
of the operator, without any info about its semantics. That doesn't
seem very cool. Now, in a quick look at the callers, it looks like it'd
be no problem from the callers' standpoint to switch things around to do
colname selection on the parsed tree instead, ie the existing choice is
for FigureColname's benefit not the callers'. But it'd likely cost
a good deal to do it the other way, since now FigureColname would need
to perform catalog lookups to get column and function names.

Maybe you could do something like passing *both* trees to FigureColname,
and let it obtain the actual operator OID from the parsed tree when the
raw tree contains AEXPR_OP. But the recursion in FigureColname would be
difficult to manage because the two trees often don't match one-to-one.

On the whole, I'm on the side of the people who don't want to change this.
The implementation cost seems likely to greatly outweigh the value, plus
it feels more like a wart than a feature.

regards, tom lane