From: Peter Gulutzan <pgulutzan@ocelot.ca> To: Imeev Mergen <imeevma@tarantool.org>, 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 Subject: Re: [Tarantool-discussions] Implicit cast for ASSIGNMENT Date: Thu, 30 Apr 2020 10:04:37 -0600 [thread overview] Message-ID: <3baee836-8404-bfaf-1c3a-353a379861d0@ocelot.ca> (raw) In-Reply-To: <37b646d1-39a3-f39a-c436-f315fe1359a0@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
next prev parent reply other threads:[~2020-04-30 16:04 UTC|newest] Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-02-13 14:25 Mergen Imeev 2020-02-13 14:40 ` Konstantin Osipov 2020-02-13 22:20 ` Peter Gulutzan 2020-04-30 12:04 ` Imeev Mergen 2020-04-30 12:35 ` Konstantin Osipov 2020-04-30 12:56 ` Imeev Mergen 2020-04-30 13:09 ` Konstantin Osipov 2020-04-30 13:12 ` Imeev Mergen 2020-04-30 14:04 ` Konstantin Osipov 2020-04-30 14:15 ` Peter Gulutzan 2020-04-30 14:28 ` Konstantin Osipov 2020-04-30 14:40 ` Peter Gulutzan 2020-04-30 15:10 ` Imeev Mergen 2020-04-30 16:04 ` Peter Gulutzan [this message] 2020-05-07 16:14 ` Peter Gulutzan 2020-05-08 11:57 ` Kirill Yukhin 2020-04-30 22:52 ` [Tarantool-discussions] Descriptive SQL Style Guide Peter Gulutzan
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=3baee836-8404-bfaf-1c3a-353a379861d0@ocelot.ca \ --to=pgulutzan@ocelot.ca \ --cc=alexander.turenko@tarantool.org \ --cc=imeevma@tarantool.org \ --cc=korablev@tarantool.org \ --cc=kostja.osipov@gmail.com \ --cc=kyukhin@tarantool.org \ --cc=tarantool-discussions@dev.tarantool.org \ --cc=tsafin@tarantool.org \ --cc=v.shpilevoy@tarantool.org \ --subject='Re: [Tarantool-discussions] Implicit cast for ASSIGNMENT' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox