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 998B74696C3 for ; Thu, 30 Apr 2020 19:04:43 +0300 (MSK) References: <20200213142534.GA26443@tarantool.org> <36e21524-35d7-9f54-5953-32863df95709@tarantool.org> <37b646d1-39a3-f39a-c436-f315fe1359a0@tarantool.org> From: Peter Gulutzan Message-ID: <3baee836-8404-bfaf-1c3a-353a379861d0@ocelot.ca> Date: Thu, 30 Apr 2020 10:04:37 -0600 MIME-Version: 1.0 In-Reply-To: <37b646d1-39a3-f39a-c436-f315fe1359a0@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, On 2020-04-30 9:10 a.m., Imeev Mergen wrote: > Hi, > > On 4/30/20 5:40 PM, Peter Gulutzan wrote: >> 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. > True. > >> > 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. > No, I plan to fix it. I already have a fix, and I plan to push it > among the patches for this problem. > I didn't expect that. Why is the current behaviour bad? >> > 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. So far, nobody has objected to your statement "Implicit casting is prohibited, except as described above." or to my statement "Implicit cast of string to number was a mistake." Therefore INSERT INTO t (integer_column) VALUES ('1'); will be illegal. This is a change in documented behaviour. Should there be a note about deprecation in the manual? >> All comparison of values of different data types should be legal. > Not sure if we should discuss comparison here, however, do you > mean that we should allow comparison of values ​​of different types > without implicit casting? Using scalar rules? > Yes. And maybe you sympathize, if you want to fix issue#4783. But you are right, this is not the topic to be discussed now. >> 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? > Yes. > >> > 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? > I'd like to get more definite answers. > >> >> Peter Gulutzan Peter Gulutzan