From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <korablev@tarantool.org>
Received: from smtpng1.m.smailru.net (smtpng1.m.smailru.net [94.100.181.251])
 (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 C512B430D56
 for <tarantool-patches@dev.tarantool.org>;
 Mon, 28 Oct 2019 17:08:52 +0300 (MSK)
Date: Mon, 28 Oct 2019 17:08:51 +0300
From: Nikita Pettik <korablev@tarantool.org>
Message-ID: <20191028140851.GA86205@tarantool.org>
References: <cover.1572211914.git.v.shpilevoy@tarantool.org>
 <8260c85a5b81a174b45b101c2e9ad5d251e7420f.1572211914.git.v.shpilevoy@tarantool.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <8260c85a5b81a174b45b101c2e9ad5d251e7420f.1572211914.git.v.shpilevoy@tarantool.org>
Subject: Re: [Tarantool-patches] [PATCH 2/3] sql: CAST(<boolean> AS TEXT)
	returns lowercase
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: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Cc: tarantool-patches@freelists.org, tarantool-patches@dev.tarantool.org

On 27 Oct 22:35, Vladislav Shpilevoy wrote:
> Implicit cast uses lowercase, and the patch makes the
> explicit cast the same.
> 
> No any special reason behind that. Lower case is
> already used much more often, so it is easier to drop
> the upper case.
> 
> Part of #4462
> ---

Oh, unfortunately I've remembered the reason of using uppercase: it is
said so by ANSI (2011):

6.13 <cast specification>

...

11) If TD is variable-length character string or large object character
string, then let MLTD be the maximum length in characters of TD.

...

e) If SD is boolean, then

Case:

i) If SV is True and MLTD is not less than 4, then TV is 'TRUE'.

ii) If SV is False and MLTD is not less than 5, then TV is 'FALSE'

...

As for implicit cast - it is allowed neither in ANSI nor in Tarantool SQL.
However, some functions (like length or group_concat) anyway provide implicit
conversion from boolean to string. Why not simply disallow that?
Earlier I suggested to remove all dispatching logic from built-ins
implementations and instead generate OP_ApplyType with function's argument
and its assumed type. AfAIR Mergen faced some problems with that, but I
believe it is likely to be most general and correct solution.