Tarantool development patches archive
 help / color / mirror / Atom feed
From: Mergen Imeev <imeevma@tarantool.org>
To: "n.pettik" <korablev@tarantool.org>
Cc: tarantool-patches@freelists.org
Subject: [tarantool-patches] Re: [PATCH v1 1/1] sql: rework SQL errors of type "expected column count"
Date: Tue, 11 Jun 2019 11:40:26 +0300	[thread overview]
Message-ID: <20190611084025.GA27968@tarantool.org> (raw)
In-Reply-To: <4C0F73A6-4BD5-4D29-891A-57B47374B463@tarantool.org>

On Thu, Jun 06, 2019 at 10:22:49PM +0300, n.pettik wrote:
> 
> >>> /*
> >>> * !IMPORTANT! Please follow instructions at start of the file
> >>> diff --git a/src/box/sql/expr.c b/src/box/sql/expr.c
> >>> index ba7eea5..8cf4d2e 100644
> >>> --- a/src/box/sql/expr.c
> >>> +++ b/src/box/sql/expr.c
> >>> @@ -2958,28 +2958,22 @@ sqlCodeSubselect(Parse * pParse,	/* Parsing context */
> >>> * Expr pIn is an IN(...) expression. This function checks that the
> >>> * sub-select on the RHS of the IN() operator has the same number of
> >>> * columns as the vector on the LHS. Or, if the RHS of the IN() is not
> >>> - * a sub-query, that the LHS is a vector of size 1.
> >>> + * a sub-query, that the LHS must be a vector of size 1.
> >> 
> >> What is the point of changing this comment?
> >> 
> > In SQlite it wasn't possible to write something like
> > "SELECT (1,2) in ..." so if length of the vector were more
> > than 1 it means it was received using subselect. It isn't
> > so in our case since we can work with such statements.
> > To emphasize this, I changed the comment.
> 
> ‘… is a vector…’ -> ‘… must be a vector…'
> 
> In context of comment they mean the same ->
> meaningless change. 
> 
Fixed.

> > New patch:
> > 
> > From 32b665f9ad9dacc16a492c55396dd843f9a355e9 Mon Sep 17 00:00:00 2001
> > Date: Sat, 18 May 2019 13:15:58 +0300
> > Subject: [PATCH] sql: rework SQL errors of type "expected column count"
> > 
> > Before this patch, errors of type "expected column count" were
> > divided into several different errors, and they all had an
> > ER_SQL_PARSER_GENERIC error code. This patch creates a new error
> > code for these errors.
> > 
> > In addition, at some point it became possible to use vectors as
> > the left value in the IN operator. Since this was previously
> > impossible, it led to a segmentation error.
> 
> This doesn’t seem to be decent description, at least to me.
> Please, provide description of problem in details: since it
> was assertion fault I guess it deserves to be explained.
> 
> Let me help you:
> 
> In SQL it is allowed to use vector expressions, i.e.
> * brief description of vector expressions *.
> For instance, * example of using vector expressions *
> Accidentally, routines handling IN operator and vector
> expressions contained bug. * Bug description *
> Let’s fix it in the following way. * Fix description *
> 
> 
Fixed:

sql: allow to use vectors as left value of IN operator

In SQL, it is allowed to use vector expressions, that is, an
operation that uses vectors as operands. For instance, vector
comparison:
SELECT (1,2,3) < (1,2,4);

Accidentally, routines handling IN operator contained a bug: in
cases where we used a vector as the left value in the IN operator,
we received an assertion or a segmentation error.
Let's fix this by allowing vectors as the left value in the IN
operator and using additional checks.

Closes #4204

  reply	other threads:[~2019-06-11  8:40 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-18 10:53 [tarantool-patches] " imeevma
2019-05-19 14:38 ` [tarantool-patches] " n.pettik
2019-05-25 11:12   ` Mergen Imeev
2019-06-06 19:22     ` n.pettik
2019-06-11  8:40       ` Mergen Imeev [this message]
2019-06-25 14:19         ` Mergen Imeev
2019-06-25 17:31           ` n.pettik
2019-06-28 16:15           ` Vladimir Davydov
2019-06-29 10:33             ` Mergen Imeev
2019-07-03  9:58               ` Vladimir Davydov

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=20190611084025.GA27968@tarantool.org \
    --to=imeevma@tarantool.org \
    --cc=korablev@tarantool.org \
    --cc=tarantool-patches@freelists.org \
    --subject='[tarantool-patches] Re: [PATCH v1 1/1] sql: rework SQL errors of type "expected column count"' \
    /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