From: Mergen Imeev <imeevma@tarantool.org> To: Nikita Pettik <korablev@tarantool.org> Cc: tarantool-patches@dev.tarantool.org Subject: Re: [Tarantool-patches] [PATCH v4 2/3] sql: fix implicit cast from STRING to INTEGER Date: Fri, 10 Apr 2020 21:09:11 +0300 [thread overview] Message-ID: <20200410180911.GA28782@tarantool.org> (raw) In-Reply-To: <20200410125757.GB9428@tarantool.org> Hi! Thank you for the review. I extended commit-message. You can see it below. On Fri, Apr 10, 2020 at 12:57:57PM +0000, Nikita Pettik wrote: > On 10 Apr 13:41, Mergen Imeev wrote: > > On Fri, Mar 27, 2020 at 04:54:17PM +0000, Nikita Pettik wrote: > > > On 27 Mar 14:33, imeevma@tarantool.org wrote: > > > > Prior to this patch, STRING, which contains the DOUBLE value, > > > > could be implicitly cast to INTEGER. This was done by converting > > > > STRING to DOUBLE and then converting this DOUBLE value to INTEGER. > > > > This may affect the accuracy of CAST(), so it was forbidden. > > > > > > > > Example: > > > > box.execute("CREATE TABLE t(i INT PRIMARY KEY);") > > > > > > > > Before patch: > > > > box.execute("INSERT INTO t VALUES ('111.1');") > > > > box.execute("SELECT * FROM t;") > > > > Result: 111 > > > > > > > > After patch: > > > > box.execute("INSERT INTO t VALUES ('1.1');") > > > > Result: 'Type mismatch: can not convert 1.1 to integer' > > > > > > > > box.execute("INSERT INTO t VALUES ('1.0');") > > > > Result: 'Type mismatch: can not convert 1.0 to integer' > > > > > > > > box.execute("INSERT INTO t VALUES ('1.');") > > > > Result: 'Type mismatch: can not convert 1. to integer' > > > > > > Is comparison predicat affected? > > > > > No, since all implicit casts in case of comparison executed > > inside of comparisons opcodes. > > You should have mentioned this fact in commit message. > Fixed: sql: fix implicit cast from STRING to INTEGER Prior to this patch, STRING, which contains the DOUBLE value, could be implicitly cast to INTEGER. This was done by converting STRING to DOUBLE and then converting this DOUBLE value to INTEGER. This may affect the accuracy of CAST(), so it was forbidden. It is worth noting that these changes will not affect the comparison, since the implicit cast in this case has different mechanics. Example: box.execute("CREATE TABLE t(i INT PRIMARY KEY);") Before patch: box.execute("INSERT INTO t VALUES ('111.1');") box.execute("SELECT * FROM t;") Result: 111 After patch: box.execute("INSERT INTO t VALUES ('1.1');") Result: 'Type mismatch: can not convert 1.1 to integer' box.execute("INSERT INTO t VALUES ('1.0');") Result: 'Type mismatch: can not convert 1.0 to integer' box.execute("INSERT INTO t VALUES ('1.');") Result: 'Type mismatch: can not convert 1. to integer' @TarantoolBot document Title: disallow cast from STRING contains DOUBLE to INTEGER After the last two patches, explicit and implicit casting from the string containing DOUBLE to INTEGER directly will be prohibited. The user must use the explicit cast to DOUBLE before the explicit or implicit cast to INTEGER. The reason for this is that before these patches, such STRINGs were implicitly cast to DOUBLE, and then this DOUBLE was implicitly or explicitly cast to INTEGER. Because of this, the result of such a cast may differ from what the user expects, and the user may not know why. It is worth noting that these changes will not affect the comparison, since the implicit cast in this case has different mechanics. Example for implicit cast: box.execute("CREATE TABLE t(i INT PRIMARY KEY);") -- Does not work anymore: box.execute("INSERT INTO t VALUES ('1.1');") -- Right way: box.execute("INSERT INTO t VALUES (CAST('1.1' AS DOUBLE));") Example for explicit cast: -- Does not work anymore: box.execute("SELECT CAST('1.1' AS INTEGER);") -- Right way: box.execute("SELECT CAST(CAST('1.1' AS DOUBLE) AS INTEGER);") > LGTM otherwise. >
next prev parent reply other threads:[~2020-04-10 18:09 UTC|newest] Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-03-27 11:33 [Tarantool-patches] [PATCH v4 0/3] sql: fix CAST() from BLOB " imeevma 2020-03-27 11:33 ` [Tarantool-patches] [PATCH v4 1/3] sql: fix CAST() from STRING " imeevma 2020-03-27 16:46 ` Nikita Pettik 2020-04-10 10:39 ` Mergen Imeev 2020-04-10 10:43 ` Mergen Imeev 2020-04-10 13:05 ` Nikita Pettik 2020-04-10 17:06 ` Imeev Mergen 2020-04-15 11:13 ` Nikita Pettik 2020-04-10 12:46 ` Nikita Pettik 2020-04-10 13:05 ` Imeev Mergen 2020-03-27 11:33 ` [Tarantool-patches] [PATCH v4 2/3] sql: fix implicit cast " imeevma 2020-03-27 16:54 ` Nikita Pettik 2020-04-10 10:41 ` Mergen Imeev 2020-04-10 12:57 ` Nikita Pettik 2020-04-10 18:09 ` Mergen Imeev [this message] 2020-03-27 11:33 ` [Tarantool-patches] [PATCH v4 3/3] sql: add '\0' to the BLOB when it is cast " imeevma 2020-03-27 16:54 ` Nikita Pettik 2020-04-16 0:03 ` [Tarantool-patches] [PATCH v4 0/3] sql: fix CAST() from BLOB " Nikita Pettik
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=20200410180911.GA28782@tarantool.org \ --to=imeevma@tarantool.org \ --cc=korablev@tarantool.org \ --cc=tarantool-patches@dev.tarantool.org \ --subject='Re: [Tarantool-patches] [PATCH v4 2/3] sql: fix implicit cast from STRING to INTEGER' \ /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