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 3852D2BAB7 for ; Tue, 11 Jun 2019 04:40:30 -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 KN-MQVuLKBKa for ; Tue, 11 Jun 2019 04:40:30 -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 857762B1C1 for ; Tue, 11 Jun 2019 04:40:29 -0400 (EDT) Date: Tue, 11 Jun 2019 11:40:26 +0300 From: Mergen Imeev Subject: [tarantool-patches] Re: [PATCH v1 1/1] sql: rework SQL errors of type "expected column count" Message-ID: <20190611084025.GA27968@tarantool.org> References: <461ca6b5a31331d36ef7d23872613f0b1c0de9d0.1558176783.git.imeevma@gmail.com> <70E77545-041F-418E-828C-335A449EF4A6@tarantool.org> <20190525111234.GB9859@tarantool.org> <4C0F73A6-4BD5-4D29-891A-57B47374B463@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4C0F73A6-4BD5-4D29-891A-57B47374B463@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: "n.pettik" Cc: tarantool-patches@freelists.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