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 490A5216C1 for ; Mon, 25 Feb 2019 07:58:51 -0500 (EST) 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 yyqdDp2TP3cB for ; Mon, 25 Feb 2019 07:58:51 -0500 (EST) 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 054C32169F for ; Mon, 25 Feb 2019 07:58:50 -0500 (EST) Subject: [tarantool-patches] Re: [PATCH 2/2] sql: fix code generation for aggregate in HAVING clause References: <750fa247185a20047e0ebd3242768ec81f12ad9f.1550768589.git.korablev@tarantool.org> From: Vladislav Shpilevoy Message-ID: Date: Mon, 25 Feb 2019 15:58:49 +0300 MIME-Version: 1.0 In-Reply-To: <750fa247185a20047e0ebd3242768ec81f12ad9f.1550768589.git.korablev@tarantool.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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: Nikita Pettik , tarantool-patches@freelists.org Thanks for the patch! See 3 comments below. On 21/02/2019 21:01, Nikita Pettik wrote: > When we allowed using HAVING clause without GROUP BY (b40f2443a), one > possible combination was forgotten to be tested: > > SELECT 1 FROM te40 HAVING SUM(s1) < 0; > > In other words, resulting set contains no aggregates, but HAVING does > contain. 1. We have these tests: select5-9.10, select5-9.11, select5-9.12. They all have no aggregates in the result set, but have in HAVING. So that was not a problem. Problem was that we forgot to test a false condition. > In this case no byte-code related to aggregate execution is > emitted at all. Hence, query above equals to simple SELECT 1; > Unfortunately, result of such query is the same when condition under > HAVING clause is satisfied. 2. Did you mean **not** satisfied? > To fix this behaviour, it is enough to > indicate to byte-code generator that we should analyze aggregates not > only in ORDER BY clauses, but also in HAVING clause. > > Closes #3932 > Follow-up #2364 > --- > src/box/sql/resolve.c | 10 +++++++--- > test/sql-tap/select5.test.lua | 25 ++++++++++++++++++++++++- > 2 files changed, 31 insertions(+), 4 deletions(-) > > diff --git a/src/box/sql/resolve.c b/src/box/sql/resolve.c > index bc208cc9d..e9a1b09f7 100644 > --- a/src/box/sql/resolve.c > +++ b/src/box/sql/resolve.c > @@ -1290,12 +1290,16 @@ resolveSelectStep(Walker * pWalker, Select * p) > return WRC_Abort; > } > > - /* If there are no aggregate functions in the result-set, and no GROUP BY > - * expression, do not allow aggregates in any of the other expressions. > + /* > + * If there are no aggregate functions in the > + * result-set, and no GROUP BY or HAVING > + * expression, do not allow aggregates in any > + * of the other expressions. > */ > assert((p->selFlags & SF_Aggregate) == 0); > pGroupBy = p->pGroupBy; > - if (pGroupBy || (sNC.ncFlags & NC_HasAgg) != 0) { > + if ((pGroupBy != NULL || p->pHaving != NULL) || 3. Why do you need the braces around "pGroupBy != NULL || p->pHaving != NULL" ? > + (sNC.ncFlags & NC_HasAgg) != 0) { > assert(NC_MinMaxAgg == SF_MinMaxAgg); > p->selFlags |= > SF_Aggregate | (sNC.ncFlags & NC_MinMaxAgg);