[Tarantool-patches] [PATCH v1 2/2] sql: remove implicit cast in bitwise operations
Nikita Pettik
korablev at tarantool.org
Thu Sep 17 16:36:48 MSK 2020
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 at 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 at 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
>
More information about the Tarantool-patches
mailing list