From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.mail.ru (smtp3.mail.ru [94.100.179.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 20B00469719 for ; Wed, 11 Mar 2020 19:15:05 +0300 (MSK) Date: Wed, 11 Mar 2020 16:15:04 +0000 From: Nikita Pettik Message-ID: <20200311161504.GB29797@tarantool.org> References: <4f7cb05d8161597c0e58520b75af04167ce0b5e6.1581580784.git.imeevma@gmail.com> <20200220195821.GE95807@tarantool.org> <20200222082701.GA8044@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200222082701.GA8044@tarantool.org> Subject: Re: [Tarantool-patches] [PATCH v2 1/1] sql: limit blob size during CAST AS INTEGER List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mergen Imeev Cc: tarantool-patches@dev.tarantool.org On 22 Feb 11:27, Mergen Imeev wrote: > Hi! Thank you for review. I changed a test once again. > Diff below. > > On Thu, Feb 20, 2020 at 10:58:21PM +0300, Nikita Pettik wrote: > > On 13 Feb 11:16, imeevma@tarantool.org wrote: > > 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. > > > As I wrote in the last letter, we have a way to make sure > that with the first case everything will be in order, > without creating a duplicate of this binary value. > Obviously, that method will definitely not affect > performance. But it can lead to the part of the value that > looks like X'333300' being decoded as 33. See the example > from the last letter. > > > Diff: > > diff --git a/test/sql-tap/cast.test.lua b/test/sql-tap/cast.test.lua > index 86c0fee..74844e0 100755 > --- a/test/sql-tap/cast.test.lua > +++ b/test/sql-tap/cast.test.lua > @@ -891,13 +891,15 @@ test:do_execsql_test( > > -- > -- In some cases, the absence of '\0' could lead to an incorrect > --- result. Make sure this does not happen now. > +-- result. For example, in this case, part of the value is as > +-- follows: X'333300', which can be decoded as the number 33. 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', 0x33); > + CREATE TABLE t (a VARBINARY PRIMARY KEY, i INT, u INT); > + INSERT INTO t VALUES (X'33', 0x33, 0x00); Still don't understand the purpose of creating separate table and so on. Again: next/prev fields don't affect content of field 'A': blob is stored in msgpack alongside with its length, so OP_Column can't decode more/less bytes than indicated in msgpack. What is more, found that your implementation relies on tt_cstr() which uses static buffer which in turn restricted by 3 * 4096 bytes. So users may get wrong results of cast with ease. Example: long_str = string.rep('0', 15000) long_str = long_str..'123' box.execute(string.format("insert into test values(2, '%s')", long_str)) box.execute("select cast(s as INTEGER) from test") Result is 0 meanwhile should lead to error.