* [Tarantool-discussions] Implicit cast for ASSIGNMENT @ 2020-02-13 14:25 Mergen Imeev 2020-02-13 14:40 ` Konstantin Osipov ` (2 more replies) 0 siblings, 3 replies; 17+ messages in thread From: Mergen Imeev @ 2020-02-13 14:25 UTC (permalink / raw) To: tarantool-discussions, kostja.osipov, pgulutzan, korablev, alexander.turenko, v.shpilevoy, kyukhin 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? ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Tarantool-discussions] Implicit cast for ASSIGNMENT 2020-02-13 14:25 [Tarantool-discussions] Implicit cast for ASSIGNMENT Mergen Imeev @ 2020-02-13 14:40 ` Konstantin Osipov 2020-02-13 22:20 ` Peter Gulutzan 2020-04-30 12:04 ` Imeev Mergen 2 siblings, 0 replies; 17+ messages in thread From: Konstantin Osipov @ 2020-02-13 14:40 UTC (permalink / raw) To: Mergen Imeev; +Cc: tarantool-discussions * Mergen Imeev <imeevma@tarantool.org> [20/02/13 17:26]: I think you suggest introducing a behaviour change between minor releases without a proper deprecation procedure, which violates the published release policy. I also don't see in this email any rationale for it. Issue 3836 is a feature and has little to do with the default behaviour which you suggest a change. Tarantool should provide reasonable, expected and widespread behaviour of implicit cast in absence of CREATE CAST statement. CREATE CAST itself is a dangerous feature which is (luckily) not very widely used. I don't think we should do it at all. > 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? > -- Konstantin Osipov, Moscow, Russia ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Tarantool-discussions] Implicit cast for ASSIGNMENT 2020-02-13 14:25 [Tarantool-discussions] Implicit cast for ASSIGNMENT Mergen Imeev 2020-02-13 14:40 ` Konstantin Osipov @ 2020-02-13 22:20 ` Peter Gulutzan 2020-04-30 12:04 ` Imeev Mergen 2 siblings, 0 replies; 17+ messages in thread From: Peter Gulutzan @ 2020-02-13 22:20 UTC (permalink / raw) To: Mergen Imeev, tarantool-discussions, kostja.osipov, korablev, alexander.turenko, v.shpilevoy, kyukhin Hi, On 2020-02-13 7:25 a.m., Mergen Imeev wrote: <cut> Hi, I think that the current implicit casts for assignment (string-to-number + number-to-string) were a bad idea, but isn't Konstantin Osipov correct? That is, policy says that you cannot make this change at this time? As for the earlier matter, implicit cast for comparison, I mentioned that that too is a behaviour change, and I suggested to Nikita Pettik that the proposal should be abandoned. But I didn't change your mind by pointing at problems, and I don't have anything new to say at the moment. Peter Gulutzan ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Tarantool-discussions] Implicit cast for ASSIGNMENT 2020-02-13 14:25 [Tarantool-discussions] Implicit cast for ASSIGNMENT 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 14:40 ` Peter Gulutzan 2 siblings, 2 replies; 17+ messages in thread From: Imeev Mergen @ 2020-04-30 12:04 UTC (permalink / raw) To: tarantool-discussions, kostja.osipov, pgulutzan, korablev, alexander.turenko, v.shpilevoy, kyukhin, tsafin 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. 2) Any scalar values can be implicitly cast to SCALAR type. 3) Values of numeric types can be implicitly cast to other numeric types. 4) Implicit casting is prohibited, except as described above. I think that the rules for implicit casting when assigning value of numeric type must be the same as in C. 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? > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Tarantool-discussions] Implicit cast for ASSIGNMENT 2020-04-30 12:04 ` Imeev Mergen @ 2020-04-30 12:35 ` Konstantin Osipov 2020-04-30 12:56 ` Imeev Mergen 2020-04-30 14:40 ` Peter Gulutzan 1 sibling, 1 reply; 17+ messages in thread From: Konstantin Osipov @ 2020-04-30 12:35 UTC (permalink / raw) To: Imeev Mergen; +Cc: tarantool-discussions * Imeev Mergen <imeevma@tarantool.org> [20/04/30 15:13]: > 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. > 2) Any scalar values can be implicitly cast to SCALAR type. > 3) Values of numeric types can be implicitly cast to other numeric > types. SQL is strictly typed, there should be no implicit conversions between numeric types. The only possible exception is conversion of a lossless conversion of a numeric literal, e.g.: float_val = 1.1 -- implicitly convert decimal constant 1.1 to float > 4) Implicit casting is prohibited, except as described above. > > > I think that the rules for implicit casting when assigning value > of numeric type must be the same as in C. > -- Konstantin Osipov, Moscow, Russia https://scylladb.com ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Tarantool-discussions] Implicit cast for ASSIGNMENT 2020-04-30 12:35 ` Konstantin Osipov @ 2020-04-30 12:56 ` Imeev Mergen 2020-04-30 13:09 ` Konstantin Osipov 0 siblings, 1 reply; 17+ messages in thread From: Imeev Mergen @ 2020-04-30 12:56 UTC (permalink / raw) To: Konstantin Osipov; +Cc: tarantool-discussions On 4/30/20 3:35 PM, Konstantin Osipov wrote: > * Imeev Mergen <imeevma@tarantool.org> [20/04/30 15:13]: >> 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. >> 2) Any scalar values can be implicitly cast to SCALAR type. >> 3) Values of numeric types can be implicitly cast to other numeric >> types. > SQL is strictly typed, there should be no implicit conversions > between numeric types. > > The only possible exception is conversion of a lossless conversion > of a numeric literal, e.g.: > > float_val = 1.1 -- implicitly convert decimal constant 1.1 to float So, is it fine to implicitly cast 1.0(DOUBLE) to 1(INTEGER)? > >> 4) Implicit casting is prohibited, except as described above. >> >> >> I think that the rules for implicit casting when assigning value >> of numeric type must be the same as in C. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Tarantool-discussions] Implicit cast for ASSIGNMENT 2020-04-30 12:56 ` Imeev Mergen @ 2020-04-30 13:09 ` Konstantin Osipov 2020-04-30 13:12 ` Imeev Mergen 0 siblings, 1 reply; 17+ messages in thread From: Konstantin Osipov @ 2020-04-30 13:09 UTC (permalink / raw) To: Imeev Mergen; +Cc: tarantool-discussions * Imeev Mergen <imeevma@tarantool.org> [20/04/30 15:59]: > > The only possible exception is conversion of a lossless conversion > > of a numeric literal, e.g.: > > > > float_val = 1.1 -- implicitly convert decimal constant 1.1 to float > So, is it fine to implicitly cast 1.0(DOUBLE) to 1(INTEGER)? 1.0 is not double, it's DECIMAL. -- Konstantin Osipov, Moscow, Russia https://scylladb.com ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Tarantool-discussions] Implicit cast for ASSIGNMENT 2020-04-30 13:09 ` Konstantin Osipov @ 2020-04-30 13:12 ` Imeev Mergen 2020-04-30 14:04 ` Konstantin Osipov 0 siblings, 1 reply; 17+ messages in thread From: Imeev Mergen @ 2020-04-30 13:12 UTC (permalink / raw) To: Konstantin Osipov; +Cc: tarantool-discussions On 4/30/20 4:09 PM, Konstantin Osipov wrote: > * Imeev Mergen <imeevma@tarantool.org> [20/04/30 15:59]: >>> The only possible exception is conversion of a lossless conversion >>> of a numeric literal, e.g.: >>> >>> float_val = 1.1 -- implicitly convert decimal constant 1.1 to float >> So, is it fine to implicitly cast 1.0(DOUBLE) to 1(INTEGER)? > 1.0 is not double, it's DECIMAL. Ok, then, let's say we executed something like this: box.execute('CREATE TABLE t (i INT PRIMARY KEY);') box.execute('INSERT INTO t VALUES(CAST(1 AS DOUBLE));') Should this work of we should receive an error? > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Tarantool-discussions] Implicit cast for ASSIGNMENT 2020-04-30 13:12 ` Imeev Mergen @ 2020-04-30 14:04 ` Konstantin Osipov 2020-04-30 14:15 ` Peter Gulutzan 0 siblings, 1 reply; 17+ messages in thread From: Konstantin Osipov @ 2020-04-30 14:04 UTC (permalink / raw) To: Imeev Mergen; +Cc: tarantool-discussions * Imeev Mergen <imeevma@tarantool.org> [20/04/30 16:14]: > > On 4/30/20 4:09 PM, Konstantin Osipov wrote: > > * Imeev Mergen <imeevma@tarantool.org> [20/04/30 15:59]: > > > > The only possible exception is conversion of a lossless conversion > > > > of a numeric literal, e.g.: > > > > > > > > float_val = 1.1 -- implicitly convert decimal constant 1.1 to float > > > So, is it fine to implicitly cast 1.0(DOUBLE) to 1(INTEGER)? > > 1.0 is not double, it's DECIMAL. > Ok, then, let's say we executed something like this: > > box.execute('CREATE TABLE t (i INT PRIMARY KEY);') > box.execute('INSERT INTO t VALUES(CAST(1 AS DOUBLE));') > > Should this work of we should receive an error? I think it shouldn't because CAST(1 AS DOUBLE) is an expression, not a constant literal. -- Konstantin Osipov, Moscow, Russia https://scylladb.com ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Tarantool-discussions] Implicit cast for ASSIGNMENT 2020-04-30 14:04 ` Konstantin Osipov @ 2020-04-30 14:15 ` Peter Gulutzan 2020-04-30 14:28 ` Konstantin Osipov 0 siblings, 1 reply; 17+ messages in thread From: Peter Gulutzan @ 2020-04-30 14:15 UTC (permalink / raw) To: Konstantin Osipov, Imeev Mergen; +Cc: tarantool-discussions Hi, On 2020-04-30 8:04 a.m., Konstantin Osipov wrote: > * Imeev Mergen <imeevma@tarantool.org> [20/04/30 16:14]: >> >> On 4/30/20 4:09 PM, Konstantin Osipov wrote: >>> * Imeev Mergen <imeevma@tarantool.org> [20/04/30 15:59]: >>>>> The only possible exception is conversion of a lossless conversion >>>>> of a numeric literal, e.g.: >>>>> >>>>> float_val = 1.1 -- implicitly convert decimal constant 1.1 to float >>>> So, is it fine to implicitly cast 1.0(DOUBLE) to 1(INTEGER)? >>> 1.0 is not double, it's DECIMAL. >> Ok, then, let's say we executed something like this: >> >> box.execute('CREATE TABLE t (i INT PRIMARY KEY);') >> box.execute('INSERT INTO t VALUES(CAST(1 AS DOUBLE));') >> >> Should this work of we should receive an error? > > I think it shouldn't because CAST(1 AS DOUBLE) is an expression, > not a constant literal. > I of course think that it should work, but K. Yukhin decided it should not work. With regard to the earlier questions Unfortunately assigning 1.1 to an INTEGER fails. "Implicit casting among the numeric data types" is a mandatory feature of standard SQL, My opinion was that implicit cast should be legal https://github.com/tarantool/tarantool/issues/4216 However, K. Yukhin closed that issue. I also believed that typeof(1.0) should be DECIMAL. https://github.com/tarantool/tarantool/issues/4415 But currently typeof(1.0) is DOUBLE. Peter Gulutzan ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Tarantool-discussions] Implicit cast for ASSIGNMENT 2020-04-30 14:15 ` Peter Gulutzan @ 2020-04-30 14:28 ` Konstantin Osipov 0 siblings, 0 replies; 17+ messages in thread From: Konstantin Osipov @ 2020-04-30 14:28 UTC (permalink / raw) To: Peter Gulutzan; +Cc: tarantool-discussions * Peter Gulutzan <pgulutzan@ocelot.ca> [20/04/30 17:16]: > I of course think that it should work, > but K. Yukhin decided it should not work. > > With regard to the earlier questions > > Unfortunately assigning 1.1 to an INTEGER fails. > "Implicit casting among the numeric data types" > is a mandatory feature of standard SQL, > My opinion was that implicit cast should be legal > https://github.com/tarantool/tarantool/issues/4216 > However, K. Yukhin closed that issue. > > I also believed that typeof(1.0) should be DECIMAL. > https://github.com/tarantool/tarantool/issues/4415 > But currently typeof(1.0) is DOUBLE. 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. -- Konstantin Osipov, Moscow, Russia ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Tarantool-discussions] Implicit cast for ASSIGNMENT 2020-04-30 12:04 ` Imeev Mergen 2020-04-30 12:35 ` Konstantin Osipov @ 2020-04-30 14:40 ` Peter Gulutzan 2020-04-30 15:10 ` Imeev Mergen 1 sibling, 1 reply; 17+ messages in thread From: Peter Gulutzan @ 2020-04-30 14:40 UTC (permalink / raw) To: Imeev Mergen, tarantool-discussions, kostja.osipov, korablev, alexander.turenko, v.shpilevoy, kyukhin, tsafin 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Tarantool-discussions] Implicit cast for ASSIGNMENT 2020-04-30 14:40 ` Peter Gulutzan @ 2020-04-30 15:10 ` Imeev Mergen 2020-04-30 16:04 ` Peter Gulutzan 2020-04-30 22:52 ` [Tarantool-discussions] Descriptive SQL Style Guide Peter Gulutzan 0 siblings, 2 replies; 17+ messages in thread From: Imeev Mergen @ 2020-04-30 15:10 UTC (permalink / raw) To: Peter Gulutzan, tarantool-discussions, kostja.osipov, korablev, alexander.turenko, v.shpilevoy, kyukhin, tsafin 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 > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Tarantool-discussions] Implicit cast for ASSIGNMENT 2020-04-30 15:10 ` Imeev Mergen @ 2020-04-30 16:04 ` Peter Gulutzan 2020-05-07 16:14 ` Peter Gulutzan 2020-04-30 22:52 ` [Tarantool-discussions] Descriptive SQL Style Guide Peter Gulutzan 1 sibling, 1 reply; 17+ messages in thread From: Peter Gulutzan @ 2020-04-30 16:04 UTC (permalink / raw) To: Imeev Mergen, tarantool-discussions, kostja.osipov, korablev, alexander.turenko, v.shpilevoy, kyukhin, tsafin 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Tarantool-discussions] Implicit cast for ASSIGNMENT 2020-04-30 16:04 ` Peter Gulutzan @ 2020-05-07 16:14 ` Peter Gulutzan 2020-05-08 11:57 ` Kirill Yukhin 0 siblings, 1 reply; 17+ messages in thread From: Peter Gulutzan @ 2020-05-07 16:14 UTC (permalink / raw) To: Imeev Mergen; +Cc: tarantool-discussions 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Tarantool-discussions] Implicit cast for ASSIGNMENT 2020-05-07 16:14 ` Peter Gulutzan @ 2020-05-08 11:57 ` Kirill Yukhin 0 siblings, 0 replies; 17+ messages in thread From: Kirill Yukhin @ 2020-05-08 11:57 UTC (permalink / raw) To: Peter Gulutzan; +Cc: tarantool-discussions Hello, On 07 май 10:14, Peter Gulutzan wrote: > 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. I guess so. > 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. I don't like the idea. We were talking about NUMBERIC-NUMERIC conversions. -- Regards, Kirill Yukhin ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Tarantool-discussions] Descriptive SQL Style Guide 2020-04-30 15:10 ` Imeev Mergen 2020-04-30 16:04 ` Peter Gulutzan @ 2020-04-30 22:52 ` Peter Gulutzan 1 sibling, 0 replies; 17+ messages in thread From: Peter Gulutzan @ 2020-04-30 22:52 UTC (permalink / raw) To: tarantool-discussions, kostja.osipov; +Cc: Elena Shebunyaeva Hi, I have added a large new file on github: Descriptive SQL Style Guide https://github.com/pgulutzan/descriptive-sql-style-guide/blob/master/style.md This was not written for Tarantool but I believe that someday Tarantool will want to have an SQL style guide, since it already has a Lua style guide. So keep it in mind that I've been thinking about the issue, and maybe we can discuss it when somebody is ready for whatever changes are necessary in the manual and the test suite. Peter Gulutzan ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2020-05-08 11:57 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-02-13 14:25 [Tarantool-discussions] Implicit cast for ASSIGNMENT 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 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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox