Re: [Tarantool-patches] [PATCH v1 2/2] sql: remove implicit cast in bitwise operations

[Nikita Pettik <korablev@tarantool.org>]

On 21 Aug 15:34, Mergen Imeev wrote:
> Hi! Thank you for the review. My answer and new patch below.
> 
> On Fri, Aug 21, 2020 at 09:21:30AM +0000, Nikita Pettik wrote:
> > On 21 Aug 11:40, imeevma@tarantool.org wrote:
> > > This patch removes the implicit conversion from STRING to INTEGER from
> > > bitwise operations. However, DOUBLE can still be implicitly converted to
> > > INTEGER.
> > 
> > I see no test involving doubles in bitwise operations. Does it make
> > any sense at all?
> Even if it doesn't, it is legal to implicitly convert DOUBLE to INTEGER.
> 
> However, when I tried to add tests for this case, I found an error in my patch.
> I re-made patch. Now in these opcodes we convert MEM to INTEGER, which I tried
> to avoid in previous patch. I did this to fix a bug where result of the
> operation is DOUBLE if one of the operands is DOUBLE. It didn't help, the
> result still has DOUBLE type. I decided to left conversion since it looks right
> here because all operands must be INTEGERS. This wouldn't work for arithmetic
> operations though.

Не понял ничего..Как эта штука должна работать??
box.execute([[SELECT 3.5 | 1.3;]])                                           
 metadata:                                                                  
 name: COLUMN_1                                                           
 type: double                                                             
 rows:                                                                      
 [3] -- WTF

Давай по-честному выдавать ошибку, когда в битовые операции суем не инты.
 
> From 3515ada4b363062cf9caa5d550ea40770e8a5e65 Mon Sep 17 00:00:00 2001
> From: Mergen Imeev <imeevma@gmail.com>
> Date: Tue, 18 Aug 2020 18:18:59 +0300
> Subject: [PATCH] sql: remove implicit cast in bitwise operations
> 
> This patch removes the implicit conversion from STRING to INTEGER from
> bitwise operations. However, DOUBLE can still be implicitly converted to
> INTEGER.
> 
> Follow-up #3809
>