[Tarantool-discussions] Implicit cast for ASSIGNMENT

[Peter Gulutzan]

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