From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id E493F30D69 for ; Thu, 6 Jun 2019 15:22:52 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIlm359Q44fz for ; Thu, 6 Jun 2019 15:22:52 -0400 (EDT) Received: from smtpng3.m.smailru.net (smtpng3.m.smailru.net [94.100.177.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id 1435030D59 for ; Thu, 6 Jun 2019 15:22:52 -0400 (EDT) From: "n.pettik" Message-Id: <4C0F73A6-4BD5-4D29-891A-57B47374B463@tarantool.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_A3E20318-95FB-4614-B57D-33C8463F24E4" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Subject: [tarantool-patches] Re: [PATCH v1 1/1] sql: rework SQL errors of type "expected column count" Date: Thu, 6 Jun 2019 22:22:49 +0300 In-Reply-To: <20190525111234.GB9859@tarantool.org> References: <461ca6b5a31331d36ef7d23872613f0b1c0de9d0.1558176783.git.imeevma@gmail.com> <70E77545-041F-418E-828C-335A449EF4A6@tarantool.org> <20190525111234.GB9859@tarantool.org> Sender: tarantool-patches-bounce@freelists.org Errors-to: tarantool-patches-bounce@freelists.org Reply-To: tarantool-patches@freelists.org List-Help: List-Unsubscribe: List-software: Ecartis version 1.0.0 List-Id: tarantool-patches List-Subscribe: List-Owner: List-post: List-Archive: To: tarantool-patches@freelists.org Cc: Imeev Mergen --Apple-Mail=_A3E20318-95FB-4614-B57D-33C8463F24E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >>> /* >>> * !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. >>=20 >> What is the point of changing this comment? >>=20 > 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. =E2=80=98=E2=80=A6 is a vector=E2=80=A6=E2=80=99 -> =E2=80=98=E2=80=A6 = must be a vector=E2=80=A6' In context of comment they mean the same -> meaningless change.=20 > New patch: >=20 > =46rom 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" >=20 > 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. >=20 > 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=E2=80=99t 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=E2=80=99s fix it in the following way. * Fix description * --Apple-Mail=_A3E20318-95FB-4614-B57D-33C8463F24E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

/*
* = !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.

=E2=80=98=E2=80= =A6 is a vector=E2=80=A6=E2=80=99 -> =E2=80=98=E2=80=A6 must be a = vector=E2=80=A6'

In context of = comment they mean the same ->
meaningless = change. 

New patch:

=46rom 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=E2=80=99t 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=E2=80=99s fix it in the following way. * Fix description = *


= --Apple-Mail=_A3E20318-95FB-4614-B57D-33C8463F24E4--