Tarantool development patches archive
 help / color / mirror / Atom feed
From: "n.pettik" <korablev@tarantool.org>
To: tarantool-patches@freelists.org
Cc: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Subject: [tarantool-patches] Re: [PATCH 9/9] sql: make <search condition> accept only boolean
Date: Thu, 18 Apr 2019 20:55:46 +0300	[thread overview]
Message-ID: <6DC565F1-23AA-49CA-BB2C-AA60EE9E3593@tarantool.org> (raw)
In-Reply-To: <babeb4a1-0859-15d4-4d30-646b0de2b045@tarantool.org>


>> <search condition> is a predicate used as a part of WHERE and
>> JOIN clauses. ANSI SQL states that <search condition> must
>> accept only boolean arguments. In our SQL it is implemented as
>> bytecode instruction OP_If which in turn carries out logic of
>> conditional jump. Since it can be involved in executing other routines
>> different from <search condition>, 
> 
> 1. Which other routines? What is a valid case of OP_If with non-boolean
> value in check?

For instance, to verify that register containing LIMIT value is > 0.
It is quite hard to track values which come to this opcode, so we
can’t be sure that it always accepts booleans.

>> we pass to it additional argument
>> when generating bytecode for WHERE and JOIN clauses. When VDBE performs
>> OP_If and detects such flag, it checks passed argument to be boolean.
>> 
>> Closes #3723
> 
> 2. In addition, it fixes https://github.com/tarantool/tarantool/issues/3651,
> doesn't it?

It does, added label.

>> diff --git a/test/sql-tap/e_delete.test.lua b/test/sql-tap/e_delete.test.lua
>> index a58dc87c7..374a7d3e4 100755
>> --- a/test/sql-tap/e_delete.test.lua
>> +++ b/test/sql-tap/e_delete.test.lua
>> @@ -89,15 +89,15 @@ test:do_delete_tests("e_delete-1.1", {
>> -- NULL are retained.
>> --
>> test:do_delete_tests("e_delete-1.2", {
>> -    {1, "DELETE FROM t3 WHERE 1       ; SELECT x FROM t3", {}},
>> -    {2, "DELETE FROM t4 WHERE 0  ; SELECT x FROM t4", {1, 2, 3, 4, 5}},
>> -    {3, "DELETE FROM t4 WHERE 0.0     ; SELECT x FROM t4", {1, 2, 3, 4, 5}},
>> +    {1, "DELETE FROM t3 WHERE true       ; SELECT x FROM t3", {}},
>> +    {2, "DELETE FROM t4 WHERE false  ; SELECT x FROM t4", {1, 2, 3, 4, 5}},
>> +    {3, "DELETE FROM t4 WHERE false    ; SELECT x FROM t4", {1, 2, 3, 4, 5}},
> 
> 3. The last two lines are exactly the same. Why not to drop one?

Ok, dropped.

>>     {4, "DELETE FROM t4 WHERE NULL    ; SELECT x FROM t4", {1, 2, 3, 4, 5}},
>>     {5, "DELETE FROM t4 WHERE y!='two'; SELECT x FROM t4", {2}},
>>     {6, "DELETE FROM t4 WHERE y='two' ; SELECT x FROM t4", {}},
>>     {7, "DELETE FROM t5 WHERE x=(SELECT max(x) FROM t5);SELECT x FROM t5", {1, 2, 3, 4}},
>>     {8, "DELETE FROM t5 WHERE (SELECT max(x) FROM t4)  ;SELECT x FROM t5", {1, 2, 3, 4}},
>> -    {9, "DELETE FROM t5 WHERE (SELECT max(x) FROM t6)  ;SELECT x FROM t5", {}},
>> +    {9, "DELETE FROM t5 WHERE (SELECT max(x) FROM t6) != 0  ;SELECT x FROM t5", {}},
>>     {10, "DELETE FROM t6 WHERE y>'seven' ; SELECT y FROM t6", {"one", "four", "five"}},
>> })
>> 
>> diff --git a/test/sql-tap/e_select1.test.lua b/test/sql-tap/e_select1.test.lua
>> index 970eeeed9..e47b0f43d 100755
>> --- a/test/sql-tap/e_select1.test.lua
>> +++ b/test/sql-tap/e_select1.test.lua
>> @@ -448,15 +448,15 @@ test:do_select_tests(
>> -- true are included from the dataset.
>> --
>> local data ={
>> -    {"1"," SELECT * FROM t1 JOIN_PATTERN t2 ON (1) ",t1_cross_t2},
>> -    {"2"," SELECT * FROM t1 JOIN_PATTERN t2 ON (0) ",{}},
>> +    {"1"," SELECT * FROM t1 JOIN_PATTERN t2 ON (true) ",t1_cross_t2},
>> +    {"2"," SELECT * FROM t1 JOIN_PATTERN t2 ON (false) ",{}},
>>     {"3"," SELECT * FROM t1 JOIN_PATTERN t2 ON (NULL) ",{}},
>> -    {"6"," SELECT * FROM t1 JOIN_PATTERN t2 ON (0.9) ",t1_cross_t2},
>> -    {"7"," SELECT * FROM t1 JOIN_PATTERN t2 ON ('0.9') ",t1_cross_t2},
>> -    {"8"," SELECT * FROM t1 JOIN_PATTERN t2 ON (0.0) ",{}},
>> +    {"6"," SELECT * FROM t1 JOIN_PATTERN t2 ON (true) ",t1_cross_t2},
>> +    {"7"," SELECT * FROM t1 JOIN_PATTERN t2 ON (true) ",t1_cross_t2},
>> +    {"8"," SELECT * FROM t1 JOIN_PATTERN t2 ON (true) ",t1_cross_t2},
> 
> 4. The same. 3 duplicates.

Removed duplicates.

  reply	other threads:[~2019-04-18 17:55 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-14 15:03 [tarantool-patches] [PATCH 0/9] Introduce type BOOLEAN in SQL Nikita Pettik
2019-04-14 15:03 ` [tarantool-patches] [PATCH 1/9] sql: refactor mem_apply_numeric_type() Nikita Pettik
2019-04-14 15:04 ` [tarantool-patches] [PATCH 2/9] sql: disallow text values participate in sum() aggregate Nikita Pettik
2019-04-16 14:12   ` [tarantool-patches] " Vladislav Shpilevoy
2019-04-18 17:54     ` n.pettik
2019-04-22 18:02       ` Vladislav Shpilevoy
2019-04-23 19:58         ` n.pettik
2019-04-14 15:04 ` [tarantool-patches] [PATCH 3/9] sql: use msgpack types instead of custom ones Nikita Pettik
2019-04-16 14:12   ` [tarantool-patches] " Vladislav Shpilevoy
2019-04-18 17:54     ` n.pettik
2019-04-22 18:02       ` Vladislav Shpilevoy
2019-04-23 19:58         ` n.pettik
2019-04-14 15:04 ` [tarantool-patches] [PATCH 4/9] sql: introduce type boolean Nikita Pettik
2019-04-16 14:12   ` [tarantool-patches] " Vladislav Shpilevoy
2019-04-18 17:54     ` n.pettik
2019-04-22 18:02       ` Vladislav Shpilevoy
2019-04-23 19:58         ` n.pettik
2019-04-23 21:06           ` Vladislav Shpilevoy
2019-04-14 15:04 ` [tarantool-patches] [PATCH 5/9] sql: improve type determination for column meta Nikita Pettik
2019-04-16 14:12   ` [tarantool-patches] " Vladislav Shpilevoy
2019-04-18 17:54     ` n.pettik
2019-04-22 18:02       ` Vladislav Shpilevoy
2019-04-23 19:58         ` n.pettik
2019-04-14 15:04 ` [tarantool-patches] [PATCH 6/9] sql: make comparison predicate return boolean Nikita Pettik
2019-04-16 14:12   ` [tarantool-patches] " Vladislav Shpilevoy
2019-04-18 17:54     ` n.pettik
2019-04-14 15:04 ` [tarantool-patches] [PATCH 7/9] sql: make predicates accept and " Nikita Pettik
2019-04-16 14:12   ` [tarantool-patches] " Vladislav Shpilevoy
2019-04-18 17:55     ` n.pettik
2019-04-14 15:04 ` [tarantool-patches] [PATCH 9/9] sql: make <search condition> accept only boolean Nikita Pettik
2019-04-16 14:12   ` [tarantool-patches] " Vladislav Shpilevoy
2019-04-18 17:55     ` n.pettik [this message]
2019-04-22 18:02       ` Vladislav Shpilevoy
2019-04-23 19:59         ` n.pettik
2019-04-23 21:06           ` Vladislav Shpilevoy
2019-04-23 22:01             ` n.pettik
     [not found] ` <b2a84f129c2343d3da3311469cbb7b20488a21c2.1555252410.git.korablev@tarantool.org>
2019-04-16 14:12   ` [tarantool-patches] Re: [PATCH 8/9] sql: make LIKE predicate return boolean result Vladislav Shpilevoy
2019-04-18 17:55     ` n.pettik
2019-04-22 18:02       ` Vladislav Shpilevoy
2019-04-23 19:58         ` n.pettik
2019-04-24 10:28 ` [tarantool-patches] Re: [PATCH 0/9] Introduce type BOOLEAN in SQL Vladislav Shpilevoy
2019-04-25  8:46 ` Kirill Yukhin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6DC565F1-23AA-49CA-BB2C-AA60EE9E3593@tarantool.org \
    --to=korablev@tarantool.org \
    --cc=tarantool-patches@freelists.org \
    --cc=v.shpilevoy@tarantool.org \
    --subject='[tarantool-patches] Re: [PATCH 9/9] sql: make <search condition> accept only boolean' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox