Tarantool development patches archive
 help / color / mirror / Atom feed
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.
>  

  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