From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cmta16.telus.net (cmta16.telus.net [209.171.16.89]) (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 7C373469710 for ; Thu, 7 May 2020 19:14:17 +0300 (MSK) From: Peter Gulutzan References: <20200213142534.GA26443@tarantool.org> <36e21524-35d7-9f54-5953-32863df95709@tarantool.org> <37b646d1-39a3-f39a-c436-f315fe1359a0@tarantool.org> <3baee836-8404-bfaf-1c3a-353a379861d0@ocelot.ca> Message-ID: Date: Thu, 7 May 2020 10:14:10 -0600 MIME-Version: 1.0 In-Reply-To: <3baee836-8404-bfaf-1c3a-353a379861d0@ocelot.ca> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Imeev Mergen Cc: tarantool-discussions@dev.tarantool.org Hi, Re this part of your proposal: >> 3) Values ​​of numeric types can be implicitly cast to other numeric Earlier I replied: >I believe this but K. Yukhin decided to close issue#4216. Update: K. Yukhin has re-opened issue#4216 Silent NUMBER cast to INTEGER https://github.com/tarantool/tarantool/issues/4216 and K. Osipov wrote: > OK, I didn't know it's ANSI. I withdraw my previous remarks and > side with Peter. Please do as he says about implicit casts of > numeric types. Therefore I believe that everyone agrees with you, "Values ​​of numeric types can be implicitly cast to other numeric" for assignments. Therefore ... This will be true for anything that has a numeric data type, now or in the planned future (DECIMAL, DOUBLE, INTEGER, NUMBER, UNSIGNED). Maybe this will be true for STRING. UPDATE table_name SET integer_column = '1.1'; I said that is bad but I don't decide. Maybe this will be true for SCALAR. You announced that you will "fix" so values have type = SCALAR. I do not know why, I do not know how, so I say "maybe". You said there will be truncation not rounding. So: CREATE TABLE t (s1 DOUBLE PRIMARY KEY, s2 INTEGER); INSERT INTO t VALUES (1.9, NULL); UPDATE t SET s2 = s1; will cause no error and no warning, s2 will contain 1. Documentation changes: Fortunately in the compliance chart I wrote https://www.tarantool.io/en/doc/2.4/book/sql/ that we support standard core feature E011-06 "Implicit casting among the numeric data types" so that does not need to be changed. Unfortunately in the SQL reference I wrote: https://www.tarantool.io/en/doc/2.4/reference/reference_sql/sql/ "From number to INTEGER or UNSIGNED is allowed for cast and assignment only if the result is not out of range, and the number has no post-decimal digits." so that does need to be changed. Peter Gulutzan