Re: [Tarantool-patches] [PATCH v2 6/6] sql: extend result set with alias

[Nikita Pettik <korablev@tarantool.org>]

On 26 Dec 14:24, Nikita Pettik wrote:
> On 24 Dec 16:34, Vladislav Shpilevoy wrote:
> > Here are solutions with which I am good:
> > 
> > - Keep the name as is, and add a new column meaning the original
> >   expression: 'orig_name', 'oname', 'span', 'column', 'expr', etc.
> >   In that case we don't break anything, we satisfy the driver, and
> >   'full_metadata' only adds new fields. It does not change the
> >   behaviour of always present columns.
> > 
> > - Or we could break the 'name' column a little, as you proposed -
> >   always return it as if AS is not specified, even in short metadata.
> >   In the full metadata it still will return the original expression,
> >   but we add a 'label' column, which returns either alias or name.
> 
> I am going to implement last option.

Okay, I've tried but it turned out to be not so easy (to be more
precise - not easy at all). The problem lies in views.
We store aliases as view column names. So changing names may
(most likely) make already existing view unable to be queried.
There's simple reason for using aliases as field names:
in case spans are taken for names, users won't be able to select
columns by names:

CREATE VIEW v1 AS SELECT a+1 FROM t; -- 'a+1' is a column name
SELECT a+1 FROM v1 -- fails: can't resolve field 'A' since real
                      field's name is 'a+1' (a+1 is considered
                      to be expression, not id).

We might think making exeption in name/label rule for views,
but from functional point of view there's no difference between
view and casual select, since first step of execution of
SELECT ... FROM VIEW ... is substitution of view body into select.

So I have to reject my initial plan and instead I am going
to follow first option from your suggestion.