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 233FC2F3EF for ; Tue, 13 Nov 2018 14:23:08 -0500 (EST) 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 sR_RcGP4RZ_J for ; Tue, 13 Nov 2018 14:23:08 -0500 (EST) Received: from smtp61.i.mail.ru (smtp61.i.mail.ru [217.69.128.41]) (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 F2F8D2F3BA for ; Tue, 13 Nov 2018 14:23:04 -0500 (EST) Date: Tue, 13 Nov 2018 22:23:05 +0300 From: Alexander Turenko Subject: [tarantool-patches] Re: [PATCH 2/2] sql: remove GLOB from Tarantool Message-ID: <20181113192305.v3uxbrp6ebqrb4gs@tkn_work_nb> References: <32D1E5EA-EA21-4E4B-B5F5-80B6578BFBED@tarantool.org> <3f8354cb-4a47-c3de-164b-c776c792b991@tarantool.org> <090683CD-6F88-492D-AF48-631220A24E36@tarantool.org> <20181021034805.alwhmkpz3fbopqjz@tkn_work_nb> <20181029121529.2d6ccnh5qayiz7ld@tkn_work_nb> <6F5AC823-3016-4918-A588-6BB6B621B777@tarantool.org> <20181109121828.mjdoouycwvonimms@tkn_work_nb> <34EFA3FE-95C1-49FC-9668-11DDD93EC42D@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <34EFA3FE-95C1-49FC-9668-11DDD93EC42D@tarantool.org> 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, korablev@tarantool.org Hi! I gave some minor comments and I think I cannot add any value anymore. Nikita N., can you look into this patch? > - if (sqlite3_strglob("unordered*", z) == 0) { > + if (sql_strlike_cs("unordered%", z, '[') == 0) > index->def->opts.stat->is_unordered = true; > - } else if (sqlite3_strglob("noskipscan*", z) == 0) { > + else if (sql_strlike_cs("noskipscan%", z, '[') == 0) > index->def->opts.stat->skip_scan_enabled = false; > - } I don't think '[' works here as it was in globs, so the parameter can be just removed. > -sqlite3_strglob(const char *zGlobPattern, const char *zString) > +sql_strlike_cs(const char *zPattern, const char *zStr, unsigned int esc) Why not UChar32, but 'unsigned int'? (It does not matter if the above is true.) See other comments below. WBR, Alexander Turenko. > > BTW, it seems that we add SQLITE_FUNC_CASE into flags, so maybe we can > > read it in likeFunc and don't pass additional parameter at all? It is > > just raw idea, I don't know the mechanics of sql functions much. > > I’m not sure it’s a good idea, at least not in terms of this patch. > Call to likeFunc comes right from OP_FUNCTION which is used for sql > functions (of course it’s not only LIKE). Thus the list of parameters is > pretty much defined there. > > (*pCtx->pFunc->xSFunc)(pCtx, pCtx->argc, pCtx->argv);/* IMP: R-24505-23230 */ > I'll leave this question to consider for the next reviewer. > >> diff --git a/test/sql-tap/collation.test.lua b/test/sql-tap/collation.test.lua > >> index eb4f43a90..dbbe1c0fe 100755 > >> --- a/test/sql-tap/collation.test.lua > >> +++ b/test/sql-tap/collation.test.lua > >> @@ -219,7 +219,7 @@ local like_testcases = > >> {0, {"Aab", "aaa"}} }, > >> {"2.1.2", > >> "EXPLAIN QUERY PLAN SELECT * FROM tx1 WHERE s1 LIKE 'A%';", > >> - {0, {0, 0, 0, "/USING COVERING INDEX I1/"}} }, > >> + {0, {0, 0, 0, "SEARCH TABLE TX1 USING COVERING INDEX I1 (S1>? AND S1 > > > What is this hunk about? > > I found that this changed message occurs even on fresh 2.1. > I was using this and few other test cases to test my patch so it was > kind of concerned with the patch and i decided to fix it at the same time. > (I don’t really think it does worth opening an issue). > I assume this issue was caused by commit 6b8acd8fde and just > wasn’t fixed. > I guess I should’ve wrote about it in the previous letter. > If so it should be separate commit. At least the message of this commit should state the changes.