From: Nikita Pettik <korablev@tarantool.org> To: imeevma@tarantool.org Cc: tarantool-patches@dev.tarantool.org Subject: Re: [Tarantool-patches] [PATCH v2 1/1] sql: limit blob size during CAST AS INTEGER Date: Thu, 20 Feb 2020 22:58:21 +0300 [thread overview] Message-ID: <20200220195821.GE95807@tarantool.org> (raw) In-Reply-To: <4f7cb05d8161597c0e58520b75af04167ce0b5e6.1581580784.git.imeevma@gmail.com> On 13 Feb 11:16, imeevma@tarantool.org wrote: > >> +test:do_execsql_test( > >> + "cast-6.1", > >> + [[ > >> + CREATE TABLE t (a VARBINARY PRIMARY KEY); > >> + INSERT INTO t VALUES (X'33'), (X'372020202020'); > >> + SELECT a, CAST(a AS NUMBER), CAST(a AS INTEGER), CAST(a AS UNSIGNED) FROM t; > >> + DROP TABLE t; > >> + ]], { > >> + -- <cast-6.1> > >> + '3', 3, 3, 3, '7 ', 7, 7, 7 > >> + -- </cast-6.1> > >> + }) > >> + > >> +test:do_execsql_test( > >> + "cast-6.2", > >> + [[ > >> + CREATE TABLE t (a VARBINARY PRIMARY KEY, i INT); > >> + INSERT INTO t VALUES (X'33', 1); > >> + SELECT a, CAST(a AS NUMBER), CAST(a AS INTEGER), CAST(a AS UNSIGNED) FROM t; > >> + DROP TABLE t; > > > > What's the (in functional sense) difference between 6.1 and 6.2? > > > True, in this test it isn't obvious what it should show. I fixed > the test. I made this test to show that the '\0' at the end of the > BLOB is important. One possible way to solve this problem was to > limit the length of the decoded BLOB (without copying and adding > '\0'), but this could lead to an incorrect result of this test. > I mean this: > > tarantool> CREATE TABLE t (a VARBINARY PRIMARY KEY, i INT) WITH ENGINE = 'vinyl'; > --- > - row_count: 1 > ... > > tarantool> INSERT INTO t VALUES (X'33', 0x33); > --- > - row_count: 1 > ... So now you insert 0x33 instead of 1 to integer field. But how does it affect test? I failed to understand. In both cases you fetch and operate on blob, meanwhile integer field doesn't seem to be involved. > > tarantool> SELECT a, CAST(a AS NUMBER), CAST(a AS INTEGER), CAST(a AS UNSIGNED) FROM t; > --- > - metadata: > - name: A > type: varbinary > - name: CAST(a AS NUMBER) > type: number > - name: CAST(a AS INTEGER) > type: integer > - name: CAST(a AS UNSIGNED) > type: unsigned > rows: > - ['3', 33, 33, 33] > ... > > +-- > +-- In some cases, the absence of '\0' could lead to an incorrect > +-- result. Make sure this does not happen now. > +-- > test:do_execsql_test( > "cast-6.2", > [[ > CREATE TABLE t (a VARBINARY PRIMARY KEY, i INT); > - INSERT INTO t VALUES (X'33', 1); > + INSERT INTO t VALUES (X'33', 0x33); > SELECT a, CAST(a AS NUMBER), CAST(a AS INTEGER), CAST(a AS UNSIGNED) FROM t; > DROP TABLE t; > ]], { >
next prev parent reply other threads:[~2020-02-20 19:58 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-02-13 8:16 imeevma 2020-02-20 19:58 ` Nikita Pettik [this message] 2020-02-22 8:27 ` Mergen Imeev 2020-03-11 16:15 ` 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=20200220195821.GE95807@tarantool.org \ --to=korablev@tarantool.org \ --cc=imeevma@tarantool.org \ --cc=tarantool-patches@dev.tarantool.org \ --subject='Re: [Tarantool-patches] [PATCH v2 1/1] sql: limit blob size during CAST AS 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