From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp32.i.mail.ru (smtp32.i.mail.ru [94.100.177.92]) (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 2856E4696C3 for ; Thu, 30 Apr 2020 18:10:18 +0300 (MSK) References: <20200213142534.GA26443@tarantool.org> <36e21524-35d7-9f54-5953-32863df95709@tarantool.org> From: Imeev Mergen Message-ID: <37b646d1-39a3-f39a-c436-f315fe1359a0@tarantool.org> Date: Thu, 30 Apr 2020 18:10:14 +0300 MIME-Version: 1.0 In-Reply-To: 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: Peter Gulutzan , 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 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. > > 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. 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? > 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 >