From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <imeevma@tarantool.org>
Received: from smtp5.mail.ru (smtp5.mail.ru [94.100.179.24])
 (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 D42B84696C3
 for <tarantool-discussions@dev.tarantool.org>;
 Thu, 30 Apr 2020 15:56:53 +0300 (MSK)
References: <20200213142534.GA26443@tarantool.org>
 <36e21524-35d7-9f54-5953-32863df95709@tarantool.org>
 <20200430123500.GA6499@atlas>
From: Imeev Mergen <imeevma@tarantool.org>
Message-ID: <8c71af0d-3693-82d5-4b15-f7b7fe38062c@tarantool.org>
Date: Thu, 30 Apr 2020 15:56:51 +0300
MIME-Version: 1.0
In-Reply-To: <20200430123500.GA6499@atlas>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Subject: Re: [Tarantool-discussions] Implicit cast for ASSIGNMENT
List-Id: Tarantool development process
 <tarantool-discussions.dev.tarantool.org>
List-Unsubscribe: <https://lists.tarantool.org/mailman/options/tarantool-discussions>, 
 <mailto:tarantool-discussions-request@dev.tarantool.org?subject=unsubscribe>
List-Archive: <https://lists.tarantool.org/pipermail/tarantool-discussions/>
List-Post: <mailto:tarantool-discussions@dev.tarantool.org>
List-Help: <mailto:tarantool-discussions-request@dev.tarantool.org?subject=help>
List-Subscribe: <https://lists.tarantool.org/mailman/listinfo/tarantool-discussions>, 
 <mailto:tarantool-discussions-request@dev.tarantool.org?subject=subscribe>
To: Konstantin Osipov <kostja.osipov@gmail.com>
Cc: tarantool-discussions@dev.tarantool.org


On 4/30/20 3:35 PM, Konstantin Osipov wrote:
> * Imeev Mergen <imeevma@tarantool.org> [20/04/30 15:13]:
>> Hi! Here we go again. Last time we have not come to a colclusion.
>>
>> So, I suggest these rules for implicit cast for ASSIGNMENT:
>> 1) Any value can be implicitly cast to ANY type.
>> 2) Any scalar values ​​can be implicitly cast to SCALAR type.
>> 3) Values ​​of numeric types can be implicitly cast to other numeric
>> types.
> SQL is strictly typed, there should be no implicit conversions
> between numeric types.
>
> The only possible exception is conversion of a lossless conversion
> of a numeric literal, e.g.:
>
> float_val = 1.1 -- implicitly convert decimal constant 1.1 to float
So, is it fine to implicitly cast 1.0(DOUBLE) to 1(INTEGER)?

>
>> 4) Implicit casting is prohibited, except as described above.
>>
>>
>> I think that the rules for implicit casting when assigning value
>> of numeric type must be the same as in C.