From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <korablev@tarantool.org>
Received: from smtpng2.m.smailru.net (smtpng2.m.smailru.net [94.100.179.3])
 (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 0252646970E
 for <tarantool-patches@dev.tarantool.org>;
 Mon, 10 Feb 2020 16:48:28 +0300 (MSK)
Date: Mon, 10 Feb 2020 16:48:27 +0300
From: Nikita Pettik <korablev@tarantool.org>
Message-ID: <20200210134827.GG1110@tarantool.org>
References: <20200207113440.79470-1-roman.habibov@tarantool.org>
 <20200210105438.GA3715@tarantool.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20200210105438.GA3715@tarantool.org>
Subject: Re: [Tarantool-patches] [PATCH] sql: fix bug <IN> type mismatch
	error
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 10 Feb 13:54, Mergen Imeev wrote:
> Hello! Thanks for the patch. In general, I think that part of the
> problem will be solved along with the solution to problem #4230
> ("sql: implicit type cast during comparison"). But since #4230 is
> still under discussion, it might be better to fix the bug with
> your patch. Still, I think that most of this patch will be
> rewritten in #4230.

Guys, result of IN operation must be equal (in all senses) to the result
of one-by-one explicit comparisons:

SELECT true IN (1, 2, 3);  <==> SELECT true == 1 OR true == 2 OR true == 3;

The latter raises an error, since there's no implicit conversion between
booleans and numerics. Hence, the goal of issue not only to make results
IN operations be equal, but rather make it return the same correct result
(i.e. as comparison does).