From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rhino.ch-server.com (rhino.ch-server.com [209.59.190.103]) (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 E826E4696C3 for ; Thu, 30 Apr 2020 17:40:46 +0300 (MSK) References: <20200213142534.GA26443@tarantool.org> <36e21524-35d7-9f54-5953-32863df95709@tarantool.org> From: Peter Gulutzan Message-ID: Date: Thu, 30 Apr 2020 08:40:42 -0600 MIME-Version: 1.0 In-Reply-To: <36e21524-35d7-9f54-5953-32863df95709@tarantool.org> 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 , tarantool-discussions@dev.tarantool.org, kostja.osipov@gmail.com, korablev@tarantool.org, alexander.turenko@tarantool.org, v.shpilevoy@tarantool.org, kyukhin@tarantool.org, tsafin@tarantool.org Hi, Going back to your original question: On 2020-04-30 6:04 a.m., Imeev Mergen wrote: > 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. This is not supported in SQL yet, I have expected that casting a scalar value to ANY would be like casting to SCALAR. > 2) Any scalar values ​​can be implicitly cast to SCALAR type. I am not sure what this means. TYPEOF(CAST(1 AS SCALAR)) is not 'scalar', it is 'integer'. That is, we allow the syntax for an explicit cast, but do nothing. So, if all you are saying is that "we allow implicit cast, but do nothing" then there is no reason to object, there is no behaviour change. > 3) Values ​​of numeric types can be implicitly cast to other numeric > types. I believe this but K. Yukhin decided to close issue#4216. > 4) Implicit casting is prohibited, except as described above. Yes, "here we go again". My opinion is unchanged: Implicit cast of string to number was a mistake. All comparison of values of different data types should be legal. Of course, assignment may cause an out-of-range error. > > > I think that the rules for implicit casting when assigning value > of numeric type must be the same as in C. > You mean there should be truncation not rounding? > On 2/13/20 5:25 PM, Mergen Imeev wrote: >> Hi all, >> I would like to discuss the second issue of casts in SQL. I mean >> implicit casting for ASSIGNMENT. >> >> For now, I suggest avoiding questions about SCALAR, as the >> discussion is already in progress. >> >> So, I suggest removing the current implicit casts. We can >> reimplement implicit casts in accordance with ANSI in issue #3836. >> But since priority of #3836 is low, this is most likely not going >> to happen for some time. >> >> At the moment, I see two ways to remove implicit casts: >> 1) Disable all implicit casts, except casts for numeric values. >> These casts will become UDCF later. >> 2) Disable all implicit casts. Assignment in Tarantool-SQL will >> work the same as in noSQL Tarantool. >> >> What do you think about this? >> For this earlier email, didn't everyone respond already? Peter Gulutzan