From: Nikita Pettik <korablev@tarantool.org> To: tarantool-patches@freelists.org Cc: Nikita Pettik <korablev@tarantool.org> Subject: [tarantool-patches] [PATCH 6/6] sql: discard numeric conversion by unary plus Date: Mon, 17 Sep 2018 23:32:30 +0300 [thread overview] Message-ID: <a195fd1d462ad0d68d84dba0ab093d0119610bbe.1537216078.git.korablev@tarantool.org> (raw) In-Reply-To: <cover.1537216077.git.korablev@tarantool.org> In-Reply-To: <cover.1537216077.git.korablev@tarantool.org> In SQLite unary plus behaves as implicit conversion to numeric type. Consider following example: CREATE TABLE t1 (id INT PRIMARY KEY, a TEXT, b BLOB); INSERT INTO t1 VALUES (1, '99', '99'); SELECT * FROM t1 WHERE a = b; (*) SELECT * FROM t1 WHERE +a = +b; (**) Since BLOB and TEXT are incompatible, result of (*) would be empty set. However, comparison in second query (**) would be of <NUMERIC> types, and result set would consist of one tuple [1, '99', '99']. Lets discard this conversion produced by unary plus, since it implicitly affects result set of query and no one other DB support such behaviour. Instead, simply use type of operand it is related to. --- src/box/sql/expr.c | 9 ++++++ test/sql-tap/whereB.test.lua | 72 ++++++++++++++++++++++---------------------- 2 files changed, 45 insertions(+), 36 deletions(-) diff --git a/src/box/sql/expr.c b/src/box/sql/expr.c index 534d856eb..aff1f35fd 100644 --- a/src/box/sql/expr.c +++ b/src/box/sql/expr.c @@ -115,6 +115,15 @@ sqlite3ExprAffinity(Expr * pExpr) &field_no); return pExpr->space_def->fields[field_no].affinity; } + /* + * In case of unary plus we shouldn't discard + * affinity of operand (since plus always features + * NUMERIC affinity). + */ + if (op == TK_UPLUS) { + assert(pExpr->pRight == NULL); + return pExpr->pLeft->affinity; + } return pExpr->affinity; } diff --git a/test/sql-tap/whereB.test.lua b/test/sql-tap/whereB.test.lua index 7e2aff078..42d90fa18 100755 --- a/test/sql-tap/whereB.test.lua +++ b/test/sql-tap/whereB.test.lua @@ -357,14 +357,14 @@ test:do_execsql_test( test:do_execsql_test( "whereB-4.4", - -- In this case the unary "+" operator removes the column affinity so - -- the columns compare false + -- In this case the unary "+" operator shouldn't + -- affect result set of query. [[ SELECT x, a, y=b FROM t1, t2 WHERE +y=+b; ]], { -- <whereB-4.4> - + 1, 2, 1 -- </whereB-4.4> }) @@ -393,14 +393,14 @@ test:do_execsql_test( test:do_execsql_test( "whereB-4.102", - -- In this case the unary "+" operator removes the column affinity so - -- the columns compare false + -- In this case the unary "+" operator shouldn't + -- affect result set of query. [[ SELECT x, a, y=b FROM t1, t2 WHERE +y=+b; ]], { -- <whereB-4.102> - + 1, 2, 1 -- </whereB-4.102> }) @@ -457,14 +457,14 @@ test:do_execsql_test( test:do_execsql_test( "whereB-5.4", - -- In this case the unary "+" operator removes the column affinity so - -- the columns compare false + -- In this case the unary "+" operator shouldn't + -- affect result set of query. [[ SELECT x, a, y=b FROM t1, t2 WHERE +y=+b; ]], { -- <whereB-5.4> - + 1, 2, 1 -- </whereB-5.4> }) @@ -493,14 +493,14 @@ test:do_execsql_test( test:do_execsql_test( "whereB-5.102", - -- In this case the unary "+" operator removes the column affinity so - -- the columns compare false + -- In this case the unary "+" operator shouldn't + -- affect result set of query. [[ SELECT x, a, y=b FROM t1, t2 WHERE +y=+b; ]], { -- <whereB-5.102> - + 1, 2, 1 -- </whereB-5.102> }) @@ -557,14 +557,14 @@ test:do_execsql_test( test:do_execsql_test( "whereB-6.4", - -- In this case the unary "+" operator removes the column affinity so - -- the columns compare false + -- In this case the unary "+" operator shouldn't + -- affect result set of query. [[ SELECT x, a, y=b FROM t1, t2 WHERE +y=+b; ]], { -- <whereB-6.4> - + 1, 2, 1 -- </whereB-6.4> }) @@ -593,14 +593,14 @@ test:do_execsql_test( test:do_execsql_test( "whereB-6.102", - -- In this case the unary "+" operator removes the column affinity so - -- the columns compare false + -- In this case the unary "+" operator shouldn't + -- affect result set of query. [[ SELECT x, a, y=b FROM t1, t2 WHERE +y=+b; ]], { -- <whereB-6.102> - + 1, 2, 1 -- </whereB-6.102> }) @@ -657,14 +657,14 @@ test:do_execsql_test( test:do_execsql_test( "whereB-7.4", - -- In this case the unary "+" operator removes the column affinity so - -- the columns compare false + -- In this case the unary "+" operator shouldn't + -- affect result set of query. [[ SELECT x, a, y=b FROM t1, t2 WHERE +y=+b; ]], { -- <whereB-7.4> - + 1, 2, 1 -- </whereB-7.4> }) @@ -693,14 +693,14 @@ test:do_execsql_test( test:do_execsql_test( "whereB-7.102", - -- In this case the unary "+" operator removes the column affinity so - -- the columns compare false + -- In this case the unary "+" operator shouldn't + -- affect result set of query. [[ SELECT x, a, y=b FROM t1, t2 WHERE +y=+b; ]], { -- <whereB-7.102> - + 1, 2, 1 -- </whereB-7.102> }) @@ -757,14 +757,14 @@ test:do_execsql_test( test:do_execsql_test( "whereB-8.4", - -- In this case the unary "+" operator removes the column affinity so - -- the columns compare false + -- In this case the unary "+" operator shouldn't + -- affect result set of query. [[ SELECT x, a, y=b FROM t1, t2 WHERE +y=+b; ]], { -- <whereB-8.4> - + 1, 2, 1 -- </whereB-8.4> }) @@ -793,14 +793,14 @@ test:do_execsql_test( test:do_execsql_test( "whereB-8.102", - -- In this case the unary "+" operator removes the column affinity so - -- the columns compare false + -- In this case the unary "+" operator shouldn't + -- affect result set of query. [[ SELECT x, a, y=b FROM t1, t2 WHERE +y=+b; ]], { -- <whereB-8.102> - + 1, 2, 1 -- </whereB-8.102> }) @@ -857,14 +857,14 @@ test:do_execsql_test( test:do_execsql_test( "whereB-9.4", - -- In this case the unary "+" operator removes the column affinity so - -- the columns compare false + -- In this case the unary "+" operator shouldn't + -- affect result set of query. [[ SELECT x, a, y=b FROM t1, t2 WHERE +y=+b; ]], { -- <whereB-9.4> - + 1, 2, 1 -- </whereB-9.4> }) @@ -893,14 +893,14 @@ test:do_execsql_test( test:do_execsql_test( "whereB-9.102", - -- In this case the unary "+" operator removes the column affinity so - -- the columns compare false + -- In this case the unary "+" operator shouldn't + -- affect result set of query. [[ SELECT x, a, y=b FROM t1, t2 WHERE +y=+b; ]], { -- <whereB-9.102> - + 1, 2, 1 -- </whereB-9.102> }) -- 2.15.1
next prev parent reply other threads:[~2018-09-17 20:33 UTC|newest] Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-09-17 20:32 [tarantool-patches] [PATCH 0/6] Introduce strict typing for SQL Nikita Pettik 2018-09-17 20:32 ` [tarantool-patches] [PATCH 1/6] sql: split conflict action and affinity for Expr Nikita Pettik 2018-09-19 2:16 ` [tarantool-patches] " Konstantin Osipov 2018-09-27 20:24 ` Vladislav Shpilevoy 2018-10-12 11:18 ` n.pettik 2018-09-17 20:32 ` [tarantool-patches] [PATCH 2/6] sql: annotate SQL functions with return type Nikita Pettik 2018-09-27 20:23 ` [tarantool-patches] " Vladislav Shpilevoy 2018-10-12 11:18 ` n.pettik 2018-09-17 20:32 ` [tarantool-patches] [PATCH 3/6] sql: pass true types of columns to Tarantool Nikita Pettik 2018-09-19 2:23 ` [tarantool-patches] " Konstantin Osipov 2018-10-12 11:19 ` n.pettik 2018-09-27 20:23 ` Vladislav Shpilevoy 2018-10-12 11:18 ` n.pettik 2018-10-17 21:45 ` Vladislav Shpilevoy 2018-10-23 23:28 ` n.pettik 2018-10-29 21:32 ` Vladislav Shpilevoy 2018-11-02 2:36 ` n.pettik 2018-09-17 20:32 ` [tarantool-patches] [PATCH 4/6] sql: enforce implicit type conversions Nikita Pettik 2018-09-19 2:25 ` [tarantool-patches] " Konstantin Osipov 2018-09-27 20:24 ` Vladislav Shpilevoy 2018-10-12 11:19 ` n.pettik 2018-10-17 21:45 ` Vladislav Shpilevoy 2018-10-23 23:28 ` n.pettik 2018-10-29 21:32 ` Vladislav Shpilevoy 2018-11-02 2:36 ` n.pettik 2018-11-02 11:15 ` Vladislav Shpilevoy 2018-11-02 13:26 ` n.pettik 2018-09-17 20:32 ` [tarantool-patches] [PATCH 5/6] sql: return result-set type via IProto Nikita Pettik 2018-09-19 2:26 ` [tarantool-patches] " Konstantin Osipov 2018-09-27 20:24 ` Vladislav Shpilevoy 2018-10-12 11:19 ` n.pettik 2018-10-17 21:45 ` Vladislav Shpilevoy 2018-10-23 23:28 ` n.pettik 2018-09-17 20:32 ` Nikita Pettik [this message] 2018-09-27 20:24 ` [tarantool-patches] Re: [PATCH 6/6] sql: discard numeric conversion by unary plus Vladislav Shpilevoy 2018-10-12 11:19 ` n.pettik 2018-09-27 20:24 ` [tarantool-patches] Re: [PATCH 0/6] Introduce strict typing for SQL Vladislav Shpilevoy 2018-10-12 11:18 ` n.pettik 2018-11-03 2:41 ` 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=a195fd1d462ad0d68d84dba0ab093d0119610bbe.1537216078.git.korablev@tarantool.org \ --to=korablev@tarantool.org \ --cc=tarantool-patches@freelists.org \ --subject='Re: [tarantool-patches] [PATCH 6/6] sql: discard numeric conversion by unary plus' \ /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