From: Roman Khabibov <roman.habibov@tarantool.org> To: tarantool-patches@freelists.org Cc: Vladislav Shpilevoy <v.shpilevoy@tarantool.org> Subject: [tarantool-patches] Re: [PATCH 1/2] sql: fix collation node duplication in AST Date: Tue, 4 Jun 2019 17:00:49 +0300 [thread overview] Message-ID: <EF36FBCD-911F-4BE4-B64D-81926CA5A9B2@tarantool.org> (raw) In-Reply-To: <e469776b-b94b-c871-2752-2ed2063a4784@tarantool.org> Hello, thanks for the review. > On Jun 2, 2019, at 8:09 PM, Vladislav Shpilevoy <v.shpilevoy@tarantool.org> wrote: > > Hi! Thanks for the fixes! See 2 comments below. > > On 28/05/2019 17:10, Roman Khabibov wrote: >> Hi! Thanks for the review. >> >>> I vote for the second as the simplest, and add a test provided by me >>> above to ensure we will never break it accidentally. >>> >>> This commit should consist of the test and a comment in resolveAlias. >>> And keep this nice ASCII schema. >> >> diff --git a/src/box/sql/resolve.c b/src/box/sql/resolve.c >> index 504096e6d..f952d8c04 100644 >> --- a/src/box/sql/resolve.c >> +++ b/src/box/sql/resolve.c >> @@ -109,6 +109,11 @@ resolveAlias(Parse * pParse, /* Parsing context */ >> return; >> if (zType[0] != 'G') >> incrAggFunctionDepth(pDup, nSubquery); >> + /* >> + * If there was typed more than one explicit collations in >> + * query, it will be a sequence of left nodes with the >> + * collations in a tree. >> + */ > > 1. Please, add a comment, that there is nothing special about > keeping the sequence. Only one collation could be stored, but > the present solution is simpler. diff --git a/src/box/sql/resolve.c b/src/box/sql/resolve.c index 504096e6d..30b9bd9d6 100644 --- a/src/box/sql/resolve.c +++ b/src/box/sql/resolve.c @@ -109,6 +109,13 @@ resolveAlias(Parse * pParse, /* Parsing context */ return; if (zType[0] != 'G') incrAggFunctionDepth(pDup, nSubquery); + /* + * If there was typed more than one explicit collations in + * query, it will be a sequence of left nodes with the + * collations in a tree. There is nothing special about + * keeping the sequence. Only one collation could be + * stored, but the present solution is simpler. + */ if (pExpr->op == TK_COLLATE) { pDup = sqlExprAddCollateString(pParse, pDup, pExpr->u.zToken); >> if (pExpr->op == TK_COLLATE) { >> pDup = >> sqlExprAddCollateString(pParse, pDup, pExpr->u.zToken); >> diff --git a/test/sql-tap/collation.test.lua b/test/sql-tap/collation.test.lua >> index 0bf54576d..3c5d3053a 100755 >> --- a/test/sql-tap/collation.test.lua >> +++ b/test/sql-tap/collation.test.lua >> @@ -529,4 +529,21 @@ test:do_catchsql_test( >> 'CREATE TABLE test3 (a int, b int, c int, PRIMARY KEY (a, a COLLATE foo, b, c))', >> {1, "Collation 'FOO' does not exist"}) >> >> +-- gh-3805 Check that collation is not ignored. Must pass. > > 2. Of course it must pass. It is the purpose of test. Please, > drop 'Must pass’. Removed. commit c409d222c500ef2b355d0c4061a3931aa6374780 Author: Roman Khabibov <roman.habibov@tarantool.org> Date: Mon May 6 14:45:51 2019 +0300 test: check that collations isn't ignored in SELECTs Add test to check that a new collation isn't ignored regardless of a name of a previous one in the following patterns of quries: SELECT s COLLATE "unicode_ci" FROM a ORDER BY s COLLATE "unicode_ci" Also note: It is disallowed to compare strings with different collations: ISO/IEC JTC 1/SC 32, Part 2: Foundation, page 531 diff --git a/src/box/sql/resolve.c b/src/box/sql/resolve.c index 504096e6d..30b9bd9d6 100644 --- a/src/box/sql/resolve.c +++ b/src/box/sql/resolve.c @@ -109,6 +109,13 @@ resolveAlias(Parse * pParse, /* Parsing context */ return; if (zType[0] != 'G') incrAggFunctionDepth(pDup, nSubquery); + /* + * If there was typed more than one explicit collations in + * query, it will be a sequence of left nodes with the + * collations in a tree. There is nothing special about + * keeping the sequence. Only one collation could be + * stored, but the present solution is simpler. + */ if (pExpr->op == TK_COLLATE) { pDup = sqlExprAddCollateString(pParse, pDup, pExpr->u.zToken); diff --git a/test/sql-tap/collation.test.lua b/test/sql-tap/collation.test.lua index 0bf54576d..9d0076e1d 100755 --- a/test/sql-tap/collation.test.lua +++ b/test/sql-tap/collation.test.lua @@ -1,6 +1,6 @@ #!/usr/bin/env tarantool test = require("sqltester") -test:plan(174) +test:plan(177) local prefix = "collation-" @@ -529,4 +529,21 @@ test:do_catchsql_test( 'CREATE TABLE test3 (a int, b int, c int, PRIMARY KEY (a, a COLLATE foo, b, c))', {1, "Collation 'FOO' does not exist"}) +-- gh-3805 Check that collation is not ignored. + +test:do_execsql_test( + "collation-2.6.0", + [[ CREATE TABLE a (id INT PRIMARY KEY, s TEXT) ]], + {}) + +test:do_execsql_test( + "collation-2.6.1", + [[ INSERT INTO a VALUES (1, 'B'), (2, 'b') ]], + {}) + +test:do_execsql_test( + "collation-2.6.2", + [[ SELECT s COLLATE "unicode_ci" FROM a ORDER BY s COLLATE "unicode" ]], + {"b","B"}) + test:finish_test()
next prev parent reply other threads:[~2019-06-04 14:00 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-05-08 11:29 [tarantool-patches] [PATCH 0/2] sql: allow <COLLATE> only for string-like args Roman Khabibov 2019-05-08 11:29 ` [tarantool-patches] [PATCH 1/2] sql: fix collation node duplication in AST Roman Khabibov 2019-05-12 16:32 ` [tarantool-patches] " Vladislav Shpilevoy 2019-05-28 14:10 ` Roman Khabibov 2019-06-02 17:09 ` Vladislav Shpilevoy 2019-06-04 14:00 ` Roman Khabibov [this message] 2019-05-08 11:29 ` [tarantool-patches] [PATCH 2/2] sql: allow <COLLATE> only for string-like args Roman Khabibov 2019-05-12 16:32 ` [tarantool-patches] " Vladislav Shpilevoy 2019-05-28 14:08 ` Roman Khabibov 2019-06-02 17:09 ` Vladislav Shpilevoy 2019-06-04 14:27 ` Roman Khabibov 2019-06-04 19:49 ` Vladislav Shpilevoy 2019-06-07 15:01 ` Roman Khabibov 2019-06-09 16:55 ` Vladislav Shpilevoy
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=EF36FBCD-911F-4BE4-B64D-81926CA5A9B2@tarantool.org \ --to=roman.habibov@tarantool.org \ --cc=tarantool-patches@freelists.org \ --cc=v.shpilevoy@tarantool.org \ --subject='[tarantool-patches] Re: [PATCH 1/2] sql: fix collation node duplication in AST' \ /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