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

[Vladislav Shpilevoy]

Ok, understood, thanks for working on this and
checking these options.

On 28/12/2019 02:44, Nikita Pettik wrote:
> 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.
>  
>