ср, 18 июл. 2018 г. в 15:34, Nikita Tatunov <hollow653@gmail.com>:

> Hello, Alexander! Please consider changes to the patch:
>
> вт, 17 июл. 2018 г. в 16:59, Alexander Turenko <
> alexander.turenko@tarantool.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).
>>
>>
> Fixed:
>
> To optimize the select-subquery tarantool uses
> subquery flattening optimization which is only used
> with respect to some restrictions. When any of
> subselects but the last one has an ORDER BY
> clause we should raise an error. So subquery
> components containing it are not accepted
> to be optimized.
>
> Checking part was only checking if the last
> subselect contains the clause which led to an
> assertion fail. With the patch applied
> flattening is not used in case any of
> subselects has an ORDER BY.
>
>
>> 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?
>>
>>
I tried to test that problem on this sqlite3 version with -DSQLITE_DEBUG
and assertion fails there.
Since flattening only makes another compound select-stmt with ORDER BY
clause I guess error was
occuring on flattened version of it. Moreover in latter versions of sqlite3
this assert was deleted and the
restriction check wasn't fixed. So I assume sqlite3 developers just don't
know about it or don't aim on
fixing it as the error anyways occurs but on flattened subquery.

> +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
>>
>
> Also fixed.
>