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 E1D17276C2 for ; Tue, 17 Jul 2018 09:59:33 -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 6UX2nvNH4nEA for ; Tue, 17 Jul 2018 09:59:33 -0400 (EDT) Received: from smtp62.i.mail.ru (smtp62.i.mail.ru [217.69.128.42]) (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 9B91627123 for ; Tue, 17 Jul 2018 09:59:33 -0400 (EDT) Date: Tue, 17 Jul 2018 16:59:34 +0300 From: Alexander Turenko Subject: [tarantool-patches] Re: [PATCH] sql: assertion fail on nested select Message-ID: <20180717135933.cc2g7rlbb2xl4kgo@tkn_work_nb> References: <1530533500-9666-1-git-send-email-hollow653@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1530533500-9666-1-git-send-email-hollow653@gmail.com> 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 Tatunov Cc: tarantool-patches@freelists.org Hi Nikita! Please, consider comments below. WBR, Alexander Turenko. On Mon, Jul 02, 2018 at 03:11:40PM +0300, N.Tatunov wrote: > To optimize the select-subquery tarantool uses > subquery flattening function which is only used > with respect to some restrictions. One of them > was implemented improperly. > Be certain: 'some restriction' and just 'improperly' are not good problem descriptions. I would use wording like the following. > When a subquery is a compound select the subquery flattening > optimization verify whether the ORDER BY clause presents, but only for > the last subquery component. The commit fixes that to verify all > subquery components. > In case of ORDER BY in non-last component of a compound select the > error should be raised. Accepting of such subqueries for the > flattening optimization prevents the error to be raised afterwards. > Instead it stuck into assertion violation inside flattenSubquery (see > the issue). I checked sqlite3 check-in 8000d230 (it is immediate predecessor of c9104b59 where the flattening optimization seems to be changed, but tarantool didn't updated with that check-in). It has the assert, but has no a change like yours, and correctly shows the following error: Error: ORDER BY clause should come after UNION ALL not before Why it is so? > +test:do_catchsql_test( > + "subquery-9.3", > + [[ > + SELECT * FROM (SELECT * FROM table1 ORDER BY 1 UNION All > + SELECT * FROM table1 UNION All > + SELECT * FROM table1); All -> ALL