From: Vladislav Shpilevoy <v.shpilevoy@tarantool.org> To: "n.pettik" <korablev@tarantool.org>, tarantool-patches@freelists.org Subject: [tarantool-patches] Re: [PATCH 7/8] sql: clean-up affinity from SQL source code Date: Tue, 22 Jan 2019 18:41:35 +0300 [thread overview] Message-ID: <2cd04a2d-6cd8-9e0b-7d51-d9431b6c5d82@tarantool.org> (raw) In-Reply-To: <541AF1EA-6688-4B4F-92CB-2AA15765A62E@tarantool.org> Thanks for the fixes! > Still some comments and variables contain ‘affinity’ term. > We can either accept it as a synonym to type, or fix > it within only code-style-fix commit. I think, we should rename. As soon as possible. Otherwise we will have 'affinity' in our code base for ages. Together with comments, dead code, already changed in this patch code, and the code you remove in the next commit my text editor found 199 'affinity' usages. It is not too much. Also, I am almost sure, that you will find some bugs during the renaming process. > commit 53561119ee99de9d5a781c5e83c49374634c4b97 > Author: Nikita Pettik <korablev@tarantool.org> > Date: Sun Dec 23 18:10:11 2018 +0200 > > sql: clean-up affinity from SQL source code > > Replace remains of affinity usage in SQL parser, query optimizer and > VDBE. Don't add affinity to field definition when table is encoded into > msgpack. Remove field type <-> affinity converters, since now we can > operate directly on field type. > > Part of #3698 See 6 comments below. > > diff --git a/src/box/sql/expr.c b/src/box/sql/expr.c > index d3a8644ce..b0a595b97 100644 > --- a/src/box/sql/expr.c > +++ b/src/box/sql/expr.c > @@ -3213,7 +3226,9 @@ sqlite3ExprCodeIN(Parse * pParse, /* Parsing and code generating context */ > if (rLhs != rLhsOrig) > sqlite3ReleaseTempReg(pParse, rLhs); > sqlite3ExprCachePop(pParse); > + sqlite3DbFree(pParse->db, aiMap); > VdbeComment((v, "end IN expr")); > + return; 1. What was wrong with the previous way of the function finalization? I do not see any functional changes in this function, but logic of freeing is different. Why? Because zAff should not be freed? Then please, fix it in the previous commit. And to do not change logic of "sqlite3ExprCodeIN_finished:" you can nullify zAff after passing it to OP_ApplyType above. > sqlite3ExprCodeIN_oom_error: > sqlite3DbFree(pParse->db, aiMap); > sqlite3DbFree(pParse->db, zAff); > diff --git a/src/box/sql/sqliteInt.h b/src/box/sql/sqliteInt.h > index 209e7bf0f..822cc40df 100644 > --- a/src/box/sql/sqliteInt.h > +++ b/src/box/sql/sqliteInt.h > @@ -1807,7 +1801,7 @@ struct Savepoint { > * operator is NULL. It is added to certain comparison operators to > * prove that the operands are always NOT NULL. > */ > -#define SQLITE_KEEPNULL 0x08 /* Used by vector == or <> */ > +#define SQLITE_KEEPNULL 0x40 /* Used by vector == or <> */ > #define SQLITE_JUMPIFNULL 0x10 /* jumps if either operand is NULL */ > #define SQLITE_STOREP2 0x20 /* Store result in reg[P2] rather than jump */ > #define SQLITE_NULLEQ 0x80 /* NULL=NULL */ 2. Please, keep them sorted. Cuts the eye. > @@ -2615,7 +2609,8 @@ struct Select { > */ > struct SelectDest { > u8 eDest; /* How to dispose of the results. On of SRT_* above. */ > - char *zAffSdst; /* Affinity used when eDest==SRT_Set */ > + /* Affinity used when eDest==SRT_Set */ > + enum field_type *zAffSdst; 3. Not affinity. > int iSDParm; /* A parameter used by the eDest disposal method */ > /** Register containing ephemeral's space pointer. */ > int reg_eph; > diff --git a/src/box/sql/vdbe.c b/src/box/sql/vdbe.c > index 61d73b676..c3f596d4f 100644 > --- a/src/box/sql/vdbe.c > +++ b/src/box/sql/vdbe.c > @@ -2163,9 +2151,16 @@ case OP_Ge: { /* same as TK_GE, jump, in1, in3 */ > break; > } > } else { > - /* Neither operand is NULL. Do a comparison. */ > - affinity = pOp->p5 & AFFINITY_MASK; > - if (affinity>=AFFINITY_INTEGER) { > + /* > + * Neither operand is NULL. Do a comparison. > + * 15 is 1111 in a binary form. > + * Since all existing types can be fitted in 4 bits > + * (field_type_MAX == 10), it is enough to 'and' > + * p5 with this constant. Node that all other flags > + * that can be stored in p5 are >= 16. > + */ > + affinity = pOp->p5 & 15; 4. Honestly, I did not expect it from you. Please, never use such constants and assumptions about them in code. field_type_MAX = 10 can be changed any day (for example, when we introduce decimal as a native Tarantool data type, or decide to add datetime). In fact, it is already not 10 - it is 9. I propose you to either come up with a better solution or to use one of my solutions: * return AFFINITY_MASK as P5_FIELD_TYPE_MASK, and add a static assertion that P5_FIELD_TYPE_MASK < (1 << bit_count(field_type)). Or write in field_def.h something like this: static_assert(bit_count(field_type) <= 4, "size of enum field_type is used in "\ "VdbeOp.p5 to fit it into 4 bits"); To get bit_count during compilation you can specify it explicitly right after field_type_MAX in enum field_type so as to change it always together with field_type_MAX. * split u16 VdbeOp.p5 into u8 VdbeOp.p6 and u8 VdbeOp.p5. But I am not sure if all p5 flags fit into u8. > + if (sql_type_is_numeric(affinity)) { > if ((flags1 | flags3)&MEM_Str) { > if ((flags1 & (MEM_Int|MEM_Real|MEM_Str))==MEM_Str) { > applyNumericAffinity(pIn1,0); > diff --git a/src/box/sql/wherecode.c b/src/box/sql/wherecode.c > index 33b860f36..01c1a2c6c 100644 > --- a/src/box/sql/wherecode.c > +++ b/src/box/sql/wherecode.c > @@ -367,15 +367,15 @@ disableTerm(WhereLevel * pLevel, WhereTerm * pTerm) > * Code an OP_ApplyType opcode to apply the column type string types > * to the n registers starting at base. > * > - * As an optimization, AFFINITY_BLOB entries (which are no-ops) at the > + * As an optimization, SCALAR entries (which are no-ops) at the > * beginning and end of zAff are ignored. If all entries in zAff are > - * AFFINITY_BLOB, then no code gets generated. > + * SCALAR, then no code gets generated. > * > * This routine makes its own copy of zAff so that the caller is free > * to modify zAff after this routine returns. > */ > static void > -codeApplyAffinity(Parse * pParse, int base, int n, char *zAff) > +codeApplyAffinity(Parse * pParse, int base, int n, enum field_type *zAff) 5. Not affinity. > { > Vdbe *v = pParse->pVdbe; > if (zAff == 0) { > @@ -419,16 +419,15 @@ codeApplyAffinity(Parse * pParse, int base, int n, char *zAff) > static void > updateRangeAffinityStr(Expr * pRight, /* RHS of comparison */ > int n, /* Number of vector elements in comparison */ > - char *zAff) /* Affinity string to modify */ > + enum field_type *zAff) /* Affinity string to modify */ 6. The same. In many other places too. Where you changed type and usages of a variable, but kept its name. > { > int i; > for (i = 0; i < n; i++) { > - enum field_type type = sql_affinity_to_field_type(zAff[i]); > Expr *p = sqlite3VectorFieldSubexpr(pRight, i); > enum field_type expr_type = sql_expr_type(p); > - if (sql_type_result(expr_type, type) == FIELD_TYPE_SCALAR || > - sql_expr_needs_no_type_change(p, type)) { > - zAff[i] = AFFINITY_BLOB; > + if (sql_type_result(expr_type, zAff[i]) == FIELD_TYPE_SCALAR || > + sql_expr_needs_no_type_change(p, zAff[i])) { > + zAff[i] = FIELD_TYPE_SCALAR; > } > } > }
next prev parent reply other threads:[~2019-01-22 15:41 UTC|newest] Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-12-28 9:34 [tarantool-patches] [PATCH 0/8] Eliminate affinity from " Nikita Pettik 2018-12-28 9:34 ` [tarantool-patches] [PATCH 1/8] sql: remove SQLITE_ENABLE_UPDATE_DELETE_LIMIT define Nikita Pettik 2018-12-29 17:42 ` [tarantool-patches] " Vladislav Shpilevoy 2019-01-16 14:25 ` n.pettik 2018-12-28 9:34 ` [tarantool-patches] [PATCH 2/8] sql: use field type instead of affinity for type_def Nikita Pettik 2018-12-29 17:42 ` [tarantool-patches] " Vladislav Shpilevoy 2019-01-16 14:26 ` n.pettik 2018-12-28 9:34 ` [tarantool-patches] [PATCH 3/8] sql: remove numeric affinity Nikita Pettik 2018-12-29 9:01 ` [tarantool-patches] " Konstantin Osipov 2018-12-29 17:42 ` Vladislav Shpilevoy 2019-01-09 8:26 ` Konstantin Osipov 2019-01-16 14:26 ` n.pettik 2019-01-22 15:41 ` Vladislav Shpilevoy 2019-01-28 16:39 ` n.pettik 2019-01-30 13:04 ` Vladislav Shpilevoy 2019-02-01 16:39 ` n.pettik 2019-01-09 8:20 ` Konstantin Osipov 2018-12-28 9:34 ` [tarantool-patches] [PATCH 4/8] sql: replace affinity with field type for func Nikita Pettik 2018-12-28 9:34 ` [tarantool-patches] [PATCH 5/8] sql: replace field type with affinity for VDBE runtime Nikita Pettik 2018-12-29 17:42 ` [tarantool-patches] " Vladislav Shpilevoy 2019-01-16 14:26 ` n.pettik 2019-01-22 15:41 ` Vladislav Shpilevoy 2019-01-28 16:39 ` n.pettik 2019-01-30 13:04 ` Vladislav Shpilevoy 2019-02-01 16:39 ` n.pettik 2019-02-05 15:08 ` Vladislav Shpilevoy 2019-02-05 17:46 ` n.pettik 2018-12-28 9:34 ` [tarantool-patches] [PATCH 6/8] sql: replace affinity with field type in struct Expr Nikita Pettik 2018-12-29 17:42 ` [tarantool-patches] " Vladislav Shpilevoy 2019-01-16 14:26 ` n.pettik 2019-01-22 15:41 ` Vladislav Shpilevoy 2019-01-28 16:39 ` n.pettik 2019-01-30 13:04 ` Vladislav Shpilevoy 2019-02-01 16:39 ` n.pettik 2019-02-05 15:08 ` Vladislav Shpilevoy 2019-02-05 17:46 ` n.pettik 2018-12-28 9:34 ` [tarantool-patches] [PATCH 7/8] sql: clean-up affinity from SQL source code Nikita Pettik 2018-12-29 17:42 ` [tarantool-patches] " Vladislav Shpilevoy 2019-01-16 14:26 ` n.pettik 2019-01-22 15:41 ` Vladislav Shpilevoy [this message] 2019-01-28 16:40 ` n.pettik 2019-01-30 13:04 ` Vladislav Shpilevoy 2019-02-01 16:39 ` n.pettik 2019-02-05 15:08 ` Vladislav Shpilevoy 2019-02-05 17:46 ` n.pettik 2018-12-28 9:34 ` [tarantool-patches] [PATCH 8/8] Remove affinity from field definition Nikita Pettik 2019-02-05 19:41 ` [tarantool-patches] Re: [PATCH 0/8] Eliminate affinity from source code Vladislav Shpilevoy 2019-02-08 13:37 ` 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=2cd04a2d-6cd8-9e0b-7d51-d9431b6c5d82@tarantool.org \ --to=v.shpilevoy@tarantool.org \ --cc=korablev@tarantool.org \ --cc=tarantool-patches@freelists.org \ --subject='[tarantool-patches] Re: [PATCH 7/8] sql: clean-up affinity from SQL source code' \ /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