From: "n.pettik" <korablev@tarantool.org> To: tarantool-patches@freelists.org Cc: Ivan Koptelov <ivan.koptelov@tarantool.org> Subject: [tarantool-patches] Re: [PATCH] sql: replace instr() with position() Date: Fri, 15 Mar 2019 20:07:13 +0300 [thread overview] Message-ID: <D4674728-C158-4E06-BA81-2BE04AA18FCB@tarantool.org> (raw) In-Reply-To: <F8ABD46B-1B57-4548-9762-B907BB0BEE36@tarantool.org> [-- Attachment #1: Type: text/plain, Size: 4002 bytes --] >> Why these conditions can’t be compatible? >> What is the difference between SQL_FUNC_NEEDCOLL >> and new flag? Does NEEDCOLL refer to returning value? >> Please, comment this part. > These conditions can’t be compatible because > SQL_FUNC_NEEDCOLL and SQL_FUNC_ARG_COLL ask for > different actions. SQL_FUNC_NEEDCOLL asks > to find first argument with collation in > the arguments expression list (from left > to right) and use it inside function > as a collation of the whole expression. > SQL_FUNC_ARG_COLL asks to check if > arguments collations are compatible > and use the right one if they are. > I would add comment to the code. > > If we want to establish proper collation > handling in all functions, we should > probably use only one flag to do check > and set the right collation. > > I would merge these flags into one, OK? Yep. >>> bool unused; >>> uint32_t id; >>> if (sql_expr_coll(pParse, >>> @@ -4064,6 +4065,37 @@ sqlExprCodeTarget(Parse * pParse, Expr * pExpr, int target) >>> return 0; >>> } >>> } >>> + if (pDef->funcFlags & SQL_FUNC_ARG_COLL) { >>> + assert(nFarg == 2); >> >> Add comment to this assertion or better to the whole branch. >> It is not obvious at first sight. Why only functions with two args… >> For instance, there’s MAX function, which may take any number >> of arguments. Collations are also vital for this function, since >> they are used to compare strings. >> >> What is more, I suggest to move this part in a separate patch, >> since position is not the only function that must apply collations >> on its operands. I don’t insist on dozens of tests on each built-in >> function, just a few. > So do you propose to make two patches: first with adding proper > collation checking/setting in sqlExprCodeTarget() and another > with adding proper collation usage in functions in func.c? > Is it OK if I put them in one patch set? Ok, you can try. Anyway, you can always squash patches. >> >>> + struct coll *colls[2] = {NULL}; >> >> I’d rather use explicit naming: >> struct coll *lhs_coll = NULL; >> struct coll *rhs_coll = NULL; >> >> It makes code a bit longer, but on the other hand IMHO >> makes it less prone to typos. > But this function sqlExprCodeTarget() is called for expression > list (of arguments). If we would use it for functions like MAX > (as we want to) then I think an array should be used. Or just > two loops to check every pair of arguments collations for > compatibility. You don’t need array: just go through arguments from left to the right and compare on compatibility their collations. >> >>> + uint32_t colls_ids[2] = {0}; >>> + bool is_forced[2] = {false}; >>> + if (sql_expr_coll(pParse, pFarg->a[0].pExpr, >>> + &is_forced[0], &colls_ids[0], >>> + &colls[0]) != 0) >>> + return 0; >>> + if (sql_expr_coll(pParse, pFarg->a[1].pExpr, >>> + &is_forced[1], &colls_ids[1], >>> + &colls[1]) != 0) >>> + return 0; >>> + >>> + uint32_t coll_id; >>> + if (collations_check_compatibility(colls_ids[0], >>> + is_forced[0], >>> + colls_ids[1], >>> + is_forced[1], >>> + &coll_id) >>> + != 0) { >>> + pParse->rc = SQL_TARANTOOL_ERROR; >>> + pParse->nErr++; >>> + return 0; >>> + } >>> + >>> + coll = (coll_id == colls_ids[0]) ? colls[0] : >>> + colls[1]; >>> + if (coll == NULL) >>> + coll = coll_by_id(COLL_NONE)->coll; >> >> Why do we need this? > Because if there is no collation at all among > arguments, then the context would not have any > collation as well. And sqlGetFuncCollSeq() > would fail with assertion in this case, because > it always expects some collations being set in context. Hm, afair we added “none” collation to avoid such situations. Will look at sql_expr_coll() and check if we can fix this. [-- Attachment #2: Type: text/html, Size: 40643 bytes --]
prev parent reply other threads:[~2019-03-15 17:07 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-03-10 7:41 [tarantool-patches] " Ivan Koptelov 2019-03-12 13:31 ` [tarantool-patches] " n.pettik 2019-03-13 11:56 ` i.koptelov 2019-03-15 17:07 ` n.pettik [this message]
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=D4674728-C158-4E06-BA81-2BE04AA18FCB@tarantool.org \ --to=korablev@tarantool.org \ --cc=ivan.koptelov@tarantool.org \ --cc=tarantool-patches@freelists.org \ --subject='[tarantool-patches] Re: [PATCH] sql: replace instr() with position()' \ /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