Tarantool development patches archive
 help / color / mirror / Atom feed
From: Nikita Pettik <korablev@tarantool.org>
To: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Cc: tarantool-patches@dev.tarantool.org
Subject: Re: [Tarantool-patches] [PATCH v2 6/6] sql: extend result set with alias
Date: Tue, 24 Dec 2019 03:26:56 +0300	[thread overview]
Message-ID: <20191224002656.GA37210@tarantool.org> (raw)
In-Reply-To: <e3100fdf-ed99-b4f3-f798-d4d53db4cd76@tarantool.org>

On 18 Dec 01:29, Vladislav Shpilevoy wrote:
> Thanks for the patch!
> 
> See 4 comments below.
> 
> 1. You didn't mention, that the PRAGMA not only regulates what
> metadata to return, but also changes 'name' field behaviour:
> 
> box.execute('PRAGMA full_metadata = true;')
> tarantool> box.execute('SELECT 1 AS label')
> ---
> - metadata:
>   - type: integer
>     name: '1'
>     alias: LABEL
>   rows:
>   - [1]
> ...
> 
> box.execute('PRAGMA full_metadata = false;')
> tarantool> box.execute('SELECT 1 AS label')
> ---
> - metadata:
>   - name: LABEL
>     type: integer
>   rows:
>   - [1]
> ...
> 
> I don't think it is ok though. Not the missing doc, but the
> not stable 'name'. It is one another reason to keep the 'name'
> as is and return the original expression span in a new column.
> 'Orig_name', 'oname', 'span', 'column', 'expr', etc.

But behaviour you suggesting contradicts all other DBs.
See my answer at the end of letter.
 
> > > diff --git a/src/box/sql/select.c b/src/box/sql/select.c
> > index d92da4d8e..c1770e7b4 100644
> > --- a/src/box/sql/select.c
> > +++ b/src/box/sql/select.c
> > @@ -1827,7 +1827,19 @@ generate_column_metadata(struct Parse *pParse, struct SrcList *pTabList,
> >  			zCol = space_def->fields[iCol].name;
> >  			const char *name = NULL;
> >  			if (pEList->a[i].zName != NULL) {
> > -				name = pEList->a[i].zName;
> > +				if (is_full_meta) {
> > +					const char *alias = NULL;
> > +					if (pEList->a[i].zSpan != NULL) {
> > +						alias = pEList->a[i].zName;
> > +						name = pEList->a[i].zSpan;
> > +					} else {
> > +						alias = pEList->a[i].zName;
> > +						name = pEList->a[i].zName;
> 
> 2. What is a point of assigning alias to the same value
> in both branches of 'if'? Couldn't you do it out of
> the 'if' and drop {} ? The same below.

It makes no sense indeed, refactored:

diff --git a/src/box/sql/select.c b/src/box/sql/select.c
index 0baabc62e..f0cf775c4 100644
--- a/src/box/sql/select.c
+++ b/src/box/sql/select.c
@@ -1829,14 +1829,11 @@ generate_column_metadata(struct Parse *pParse, struct SrcList *pTabList,
                        const char *name = NULL;
                        if (pEList->a[i].zName != NULL) {
                                if (is_full_meta) {
-                                       const char *alias = NULL;
-                                       if (pEList->a[i].zSpan != NULL) {
-                                               alias = pEList->a[i].zName;
+                                       if (pEList->a[i].zSpan != NULL)
                                                name = pEList->a[i].zSpan;
-                                       } else {
-                                               alias = pEList->a[i].zName;
+                                        else
                                                name = pEList->a[i].zName;
-                                       }
+                                       const char *alias = pEList->a[i].zName;
                                        vdbe_metadata_set_col_alias(v, i, alias);
                                } else {
                                        name = pEList->a[i].zName;
@@ -1866,14 +1863,11 @@ generate_column_metadata(struct Parse *pParse, struct SrcList *pTabList,
                        const char *z = NULL;
                        if (pEList->a[i].zName != NULL) {
                                if (is_full_meta ) {
-                                       const char *alias = NULL;
-                                       if (pEList->a[i].zSpan != NULL) {
-                                               alias = pEList->a[i].zName;
+                                       if (pEList->a[i].zSpan != NULL)
                                                z = pEList->a[i].zSpan;
-                                       } else {
-                                               alias = pEList->a[i].zName;
+                                       else
                                                z = pEList->a[i].zName;
-                                       }
+                                       const char *alias = pEList->a[i].zName;
                                        vdbe_metadata_set_col_alias(v, i, alias);

 
> > @@ -1854,9 +1866,21 @@ generate_column_metadata(struct Parse *pParse, struct SrcList *pTabList,
> >  			}
> >  		} else {
> >  			const char *z = NULL;
> > -			if (pEList->a[i].zName != NULL)
> > -				z = pEList->a[i].zName;
> > -			else if (pEList->a[i].zSpan != NULL)
> > +			if (pEList->a[i].zName != NULL) {
> > +				if (is_full_meta ) {
> 
> 3. Extra whitespace after is_full_meta.

Removed.

> > diff --git a/test/sql/full_metadata.result b/test/sql/full_metadata.result
> > index 7c2982682..8f0bced36 100644
> > --- a/test/sql/full_metadata.result
> > +++ b/test/sql/full_metadata.result
> > @@ -118,6 +121,35 @@ execute("SELECT * FROM t;")
> >   |   - [1, 1, 'aSd']
> >   | ...
> >  
> > +-- Alias is always set in extended metadata. If column label in
> > +-- form of AS clause is set, then this alias is presented in
> > +-- metadata. Otherwise, alias is just the same as name.
> 
> 4. But it is not true. The alias is not set always:
>
> =========================================================
> 
> tarantool> box.execute('PRAGMA full_metadata = true;')
> ---
> - row_count: 0
> ...
> 
> tarantool> box.execute('SELECT 1')
> ---
> - metadata:
>   - name: '1'
>     type: integer
>   rows:
>   - [1]
> ...
> 
> =========================================================
> 
> As you can see, no AS = no alias.

Always displaying alias (or label - call it whatever you want)
even in full_metadata mode doesn't seem to be reasonable for me.
Users can easily handle it in their code. Sending one map field
with string value duplicating the name and decoding it may affect
performance much more significant than one NULL check (IMHO).

> This is what I don't like
> in this patch the most. A user does not have a reliable always
> present column with a displayable name: either the column
> span or its alias after AS. He can't use name, because it
> changes its behavour depending on AS. And he can't use alias,
> because sometimes it is not present.

> That leads to confusion,
> and necessity to branch in user code a lot.

Yep, if user wants (for some reason; I don't have statistics how
often alias value can be useful or/and is used in production code)
to get alias value, one should make a small effort and add one
'if' condition:

if (is_full_metadata && alias == NULL)
    alias = name;

That's it.

Alternatively (I don't take into consideration option of swapping
name and alias as you suggest) we can change current default behaviour
and in 'casual metadata mode' return name as name (not alias):

SELECT 1 AS x; -- would return '1' as name (now it returns 'x' as name). 

But I guess some users may turn out to be confused (in case they
haven't red about full_metadata pragma in docs).

> The same example shows, that alias is a bad name. Here you need
> to return it, but it is not alias like AS. 'Label' would fit
> better here.

I don't care much how to call it. If you prefer 'label', I will rename it.
TBO I also don't care much which approach we should follow: always return
alias/label, fix current name/alias resolution, or swap name and alias
at all. If you insist on certain implementation, let's do it. If you
don't care much as well, let's ask smb else to take a final decision.

  reply	other threads:[~2019-12-24  0:26 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-11 13:44 [Tarantool-patches] [PATCH v2 0/6] sql: extended metadata Nikita Pettik
     [not found] ` <cover.1576071711.git.korablev@tarantool.org>
2019-12-11 13:44   ` [Tarantool-patches] [PATCH v2 1/6] sql: refactor resulting set metadata Nikita Pettik
2019-12-11 13:44   ` [Tarantool-patches] [PATCH v2 2/6] sql: fix possible null dereference in sql_expr_coll() Nikita Pettik
2019-12-11 13:44   ` [Tarantool-patches] [PATCH v2 3/6] sql: extend result set with collation Nikita Pettik
2019-12-18  0:29     ` Vladislav Shpilevoy
2019-12-24  0:26       ` Nikita Pettik
2019-12-24 15:30         ` Vladislav Shpilevoy
2019-12-11 13:44   ` [Tarantool-patches] [PATCH v2 4/6] sql: extend result set with nullability Nikita Pettik
2019-12-18  0:29     ` Vladislav Shpilevoy
2019-12-24  0:26       ` Nikita Pettik
2019-12-11 13:44   ` [Tarantool-patches] [PATCH v2 5/6] sql: extend result set with autoincrement Nikita Pettik
2019-12-18  0:29     ` Vladislav Shpilevoy
2019-12-24  0:26       ` Nikita Pettik
2019-12-24 15:30         ` Vladislav Shpilevoy
2019-12-25 12:17           ` Nikita Pettik
2019-12-25 15:40             ` Vladislav Shpilevoy
2019-12-25 23:18               ` Nikita Pettik
2019-12-11 13:44   ` [Tarantool-patches] [PATCH v2 6/6] sql: extend result set with alias Nikita Pettik
2019-12-18  0:29     ` Vladislav Shpilevoy
2019-12-24  0:26       ` Nikita Pettik [this message]
2019-12-24 15:34         ` Vladislav Shpilevoy
2019-12-26 11:24           ` Nikita Pettik
2019-12-27 11:53             ` Vladislav Shpilevoy
2019-12-27 23:44             ` Nikita Pettik
2019-12-28  9:29               ` Vladislav Shpilevoy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191224002656.GA37210@tarantool.org \
    --to=korablev@tarantool.org \
    --cc=tarantool-patches@dev.tarantool.org \
    --cc=v.shpilevoy@tarantool.org \
    --subject='Re: [Tarantool-patches] [PATCH v2 6/6] sql: extend result set with alias' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox