From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp57.i.mail.ru (smtp57.i.mail.ru [217.69.128.37]) (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 277A54696C3 for ; Fri, 10 Apr 2020 16:05:19 +0300 (MSK) Date: Fri, 10 Apr 2020 13:05:18 +0000 From: Nikita Pettik Message-ID: <20200410130518.GC9428@tarantool.org> References: <01024a2279b5c030f272d2a97ce8bd83f8ababc3.1585308644.git.imeevma@gmail.com> <20200327164604.GC9287@tarantool.org> <20200410103945.GA20019@tarantool.org> <20200410104352.GA20241@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200410104352.GA20241@tarantool.org> Subject: Re: [Tarantool-patches] [PATCH v4 1/3] sql: fix CAST() from STRING to 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 10 Apr 13:43, Mergen Imeev wrote: > Sorry, forgot to answer one question. > > On Fri, Apr 10, 2020 at 01:39:45PM +0300, Mergen Imeev wrote: > > Hi! Thank you for review. My answers and new patch below. > > > > On Fri, Mar 27, 2020 at 04:46:04PM +0000, Nikita Pettik wrote: > > > On 27 Mar 14:33, imeevma@tarantool.org wrote: > > > > > > Could you please find Peter's table containing current/expected cast > > > behaviours and verify that this patch doesn't contradict it? > > > > Here: > https://github.com/tarantool/doc/blob/pgulutzan-2.3/doc/reference/reference_sql/sql.rst > > ~ To BOOLEAN | To INTEGER | To NUMBER | To STRING | To VARBINARY > --------------- ---------- ---------- --------- --------- ------------ > From BOOLEAN | AAA | A-- | --- | A-- | --- > From INTEGER | A-- | AAA | AAA | AAA | --- > From NUMBER | A-- | SSA | AAA | AAA | --- > From STRING | S-- | SSS | SSS | AAA | A-- > From VARBINARY | --- | --- | --- | A-- | AAA > > Should be fine since we have S for CAST() and implicit > cast from STRING to INTEGER. This table describes current behaviour. Could you also find the table which shows expected one?