From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <korablev@tarantool.org>
Received: from smtp38.i.mail.ru (smtp38.i.mail.ru [94.100.177.98])
 (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 A0EB3469719
 for <tarantool-patches@dev.tarantool.org>;
 Thu, 17 Sep 2020 16:36:49 +0300 (MSK)
Date: Thu, 17 Sep 2020 13:36:48 +0000
From: Nikita Pettik <korablev@tarantool.org>
Message-ID: <20200917133648.GF10599@tarantool.org>
References: <cover.1597998754.git.imeevma@gmail.com>
 <56f685097fb1120e36bf03114a32d567e668a2a2.1597998754.git.imeevma@gmail.com>
 <20200821092130.GC6452@tarantool.org>
 <20200821123409.GA219863@tarantool.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20200821123409.GA219863@tarantool.org>
Subject: Re: [Tarantool-patches] [PATCH v1 2/2] sql: remove implicit cast in
	bitwise operations
List-Id: Tarantool development patches <tarantool-patches.dev.tarantool.org>
List-Unsubscribe: <https://lists.tarantool.org/mailman/options/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=unsubscribe>
List-Archive: <https://lists.tarantool.org/pipermail/tarantool-patches/>
List-Post: <mailto:tarantool-patches@dev.tarantool.org>
List-Help: <mailto:tarantool-patches-request@dev.tarantool.org?subject=help>
List-Subscribe: <https://lists.tarantool.org/mailman/listinfo/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=subscribe>
To: Mergen Imeev <imeevma@tarantool.org>
Cc: tarantool-patches@dev.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
>