Re: Proposition for autoname columns

On Thu, Nov 12, 2020 at 9:32 AM Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:

>
> On 11/12/20 11:12 AM, David G. Johnston wrote:
> > On Thu, Nov 12, 2020 at 8:59 AM Andrew Dunstan <andrew(at)dunslane(dot)net
> > <mailto:andrew(at)dunslane(dot)net>> wrote:
> >
> >
> >
> > So if we then say:
> >
> >
> > select x, j->>x from mytable;
> >
> >
> > you want both result columns named x? That seems like a recipe for
> > serious confusion. I really don't think this proposal has been
> > properly
> > thought through.
> >
> >
> > IMO It no worse than today's:
> >
> > select count(*), count(*) from (values (1), (2)) vals (v);
> > count | count
> > 2 | 2
> >
>
>
> I guess the difference here is that there's an extra level of
> indirection. So
>
>
> select x, j->>'x', j->>x from mytable
>
>
> would have 3 result columns all named x.
>
>
I totally missed the variable reference there - only two of those become
"x", the variable reference stays un-rewritten and thus results in
"?column?", similar to today:

select count(*), count(*) +1 from (values (1), (2)) vals (v);
count | ?column?
2 | 2

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). If
the RHS is a variable then there is no good name that is known to cover all
output values and thus ?column? (i.e., do not rewrite/provide an alias
clause) is an appropriate choice.

My concerns in this area involve stored views and ruleutils, dump/reload by
extension. Greenfield, this would have been nice, and worth the minimal
complexity given its usefulness in the common case, but is it useful enough
to introduce a whole new default naming mechanism and dealing with
dump/restore concerns?

David J.