From: "n.pettik" <korablev@tarantool.org> To: tarantool-patches@freelists.org Cc: Vladislav Shpilevoy <v.shpilevoy@tarantool.org> Subject: [tarantool-patches] Re: [PATCH 3/3] sql: change collation compatibility rules Date: Tue, 13 Nov 2018 02:46:34 +0300 [thread overview] Message-ID: <9E3A4492-F426-402B-808D-A31CEF743A47@tarantool.org> (raw) In-Reply-To: <b803f546-dc22-9022-74b7-72e18c84f2d9@tarantool.org> After discussion with Konstantin in @dev mailing list, we have decided to introduce real entities in _collation space to represent binary and “none” collations. Hence, I am going to send updated patch-set as second iteration (v2). Also, I’ve took your comments into consideration. >> diff --git a/src/box/sql/expr.c b/src/box/sql/expr.c >> index a13de4f0e..bd25ed656 100644 >> --- a/src/box/sql/expr.c >> +++ b/src/box/sql/expr.c >> @@ -316,25 +315,62 @@ binaryCompareP5(Expr * pExpr1, Expr * pExpr2, int jumpIfNull) >> return aff; >> } >> +int >> +collations_are_compatible(uint32_t lhs_id, bool is_lhs_forced, >> + uint32_t rhs_id, bool is_rhs_forced, >> + uint32_t *res_id) > > 1. Why not to rename to _check_compatibility() and set > diag right here? Just another way to implement this. In updated patch I did it as you suggested. >> +{ >> + assert(res_id != NULL); >> + if (is_lhs_forced && is_rhs_forced) { >> + if (lhs_id != rhs_id) >> + return -1; >> + } >> + if (is_lhs_forced) { >> + *res_id = lhs_id; >> + return 0; >> + } >> + if (is_rhs_forced) { >> + *res_id = rhs_id; >> + return 0; >> + } >> + if (lhs_id != rhs_id) { >> + if (lhs_id == COLL_NONE) { >> + *res_id = rhs_id; >> + return 0; >> + } >> + if (rhs_id == COLL_NONE) { >> + *res_id = lhs_id; >> + return 0; >> + } >> + return -1; >> + } >> + *res_id = lhs_id; >> + return 0; >> +} >> + >> struct coll * >> sql_binary_compare_coll_seq(Parse *parser, Expr *left, Expr *right, >> uint32_t *coll_id) >> { >> - struct coll *coll; >> - bool is_found; >> assert(left != NULL); >> - if ((left->flags & EP_Collate) != 0) { >> - coll = sql_expr_coll(parser, left, &is_found, coll_id); >> - } else if (right != NULL && (right->flags & EP_Collate) != 0) { >> - coll = sql_expr_coll(parser, right, &is_found, coll_id); >> - } else { >> - coll = sql_expr_coll(parser, left, &is_found, coll_id); >> - if (! is_found) { >> - coll = sql_expr_coll(parser, right, &is_found, >> - coll_id); >> - } >> + bool is_lhs_forced; >> + bool is_rhs_forced; >> + uint32_t lhs_coll_id; >> + uint32_t rhs_coll_id; >> + struct coll *lhs_coll = sql_expr_coll(parser, left, &is_lhs_forced, >> + &lhs_coll_id); >> + struct coll *rhs_coll = sql_expr_coll(parser, right, &is_rhs_forced, >> + &rhs_coll_id); >> + if (collations_are_compatible(lhs_coll_id, is_lhs_forced, >> + rhs_coll_id, is_rhs_forced, >> + coll_id) != 0) { >> + diag_set(ClientError, ER_ILLEGAL_COLLATION_MIX); >> + parser->rc = SQL_TARANTOOL_ERROR; >> + parser->nErr++; >> + *coll_id = COLL_NONE; > > 3. Why do you need to set coll_id in a case of an error? As I > understand, after an error the compilation is terminated. Just in case, it shouldn’t be really used. I removed it. > >> + return NULL; >> } >> - return coll; >> + return *coll_id == rhs_coll_id ? rhs_coll : lhs_coll;; >> } >> /* >> diff --git a/src/box/sql/select.c b/src/box/sql/select.c >> index 1ec92aac7..c3403670b 100644 >> --- a/src/box/sql/select.c >> +++ b/src/box/sql/select.c >> @@ -2035,8 +2035,9 @@ sqlite3SelectAddColumnTypeAndCollation(Parse * pParse, /* Parsing contexts */ >> bool is_found; >> uint32_t coll_id; >> if (pTab->def->fields[i].coll_id == COLL_NONE && >> - sql_expr_coll(pParse, p, &is_found, &coll_id) && is_found) >> + sql_expr_coll(pParse, p, &is_found, &coll_id) && coll_id != COLL_NONE) >> pTab->def->fields[i].coll_id = coll_id; >> + assert(pTab->def->fields[i].coll_id != COLL_BINARY); > > 4. Why? I can create a table with binary collation after the > previous commit. I guess it is debug remains. Removed. > >> } >> } >> @@ -2223,47 +2224,53 @@ computeLimitRegisters(Parse * pParse, Select * p, int iBreak) >> +static uint32_t >> +multi_select_coll_seq(struct Parse *parser, struct Select *p, int n, >> + bool *is_forced_coll) >> { >> - struct coll *coll; >> + bool is_prior_forced = false; >> + bool is_current_forced; >> + uint32_t prior_coll_id = COLL_NONE; >> + uint32_t current_coll_id; >> if (p->pPrior != NULL) { >> - coll = multi_select_coll_seq_r(parser, p->pPrior, n, is_found, >> - coll_id); >> - } else { >> - coll = NULL; >> - *coll_id = COLL_NONE; >> + prior_coll_id = multi_select_coll_seq(parser, p->pPrior, n, >> + &is_prior_forced); >> } >> - assert(n >= 0); >> - /* iCol must be less than p->pEList->nExpr. Otherwise an error would >> - * have been thrown during name resolution and we would not have gotten >> - * this far >> + /* >> + * Column number must be less than p->pEList->nExpr. >> + * Otherwise an error would have been thrown during name >> + * resolution and we would not have gotten this far. > > 5. 'have gotten'? Maybe 'have got’? Yep, fixed.
prev parent reply other threads:[~2018-11-12 23:46 UTC|newest] Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-10-25 11:00 [tarantool-patches] [PATCH 0/3] Change collation compatibility rules according to ANSI SQL Nikita Pettik 2018-10-25 11:00 ` [tarantool-patches] [PATCH 1/3] sql: do not add explicit <COLLATE "BINARY"> clause Nikita Pettik 2018-10-25 11:00 ` [tarantool-patches] [PATCH 2/3] Add surrogate ID for BINARY collation Nikita Pettik 2018-10-31 12:34 ` [tarantool-patches] " Vladislav Shpilevoy 2018-10-31 15:47 ` n.pettik 2018-11-01 11:37 ` Konstantin Osipov 2018-11-01 12:22 ` Vladislav Shpilevoy 2018-11-01 12:58 ` Konstantin Osipov 2018-11-01 13:08 ` n.pettik 2018-11-01 15:39 ` Konstantin Osipov [not found] ` <95CB17D5-E3ED-4B05-A289-983E2FD0DE37@gmail.com> 2018-11-01 17:45 ` n.pettik 2018-11-01 20:00 ` Konstantin Osipov 2018-11-01 20:06 ` Konstantin Osipov 2018-11-01 20:20 ` n.pettik 2018-10-25 11:00 ` [tarantool-patches] [PATCH 3/3] sql: change collation compatibility rules Nikita Pettik 2018-10-31 12:34 ` [tarantool-patches] " Vladislav Shpilevoy 2018-11-12 23:46 ` 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=9E3A4492-F426-402B-808D-A31CEF743A47@tarantool.org \ --to=korablev@tarantool.org \ --cc=tarantool-patches@freelists.org \ --cc=v.shpilevoy@tarantool.org \ --subject='[tarantool-patches] Re: [PATCH 3/3] sql: change collation compatibility rules' \ /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