Tarantool discussions archive
 help / color / mirror / Atom feed
* [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

* [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

* 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

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

Tarantool discussions archive

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://lists.tarantool.org/tarantool-discussions/0 tarantool-discussions/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 tarantool-discussions tarantool-discussions/ https://lists.tarantool.org/tarantool-discussions \
		tarantool-discussions@dev.tarantool.org.
	public-inbox-index tarantool-discussions

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git