[Tarantool-discussions] Implicit cast for assignment between numeric types and type mismatch error description.

[Peter Gulutzan]

Hi,

On 2020-06-22 5:52 a.m., Mergen Imeev wrote:
 > Hello Peter!
 >
 > I have two questions.
 >
 > The first. I am sorry to ask about this again, but I want to
 > discuss once again the implicit cast for assignment between
 > numeric types. I wrote earlier that I plan to use C rules for
 > implicit casting. However, after implementation, this looks
 > terribly wrong for me. Temporarily, I decided to allow implicit
 > casting only if the number after conversion from one type to
 > another using C rules and back remains unchanged. For example, a
 > double 50.0 can be implicitly cast to an integer 50, but a
 > double 50.5 cannot be cast to an integer, and an integer 2^60-1
 > cannot be cast to a double.
 >
 > However, I am not sure if this is correct. Could you suggest rules
 > for implicit casting to assign numeric types?
 >

Re "double 50.5"
On 2020-04-30 in thread (CCed to several people and to dev)
"Re: [Tarantool-discussions] Implicit cast for ASSIGNMENT"
I read:
Mergen Imeev> I think that the rules for implicit casting when assigning 
value
Mergen Imeev> of numeric type must be the same as in C.
Peter Gulutzan> You mean there should be truncation not rounding?
Mergen Imeev> Yes.
Therefore I expected
box.execute([[CREATE TABLE t0 (s1 INTEGER PRIMARY KEY);]])
box.execute([[INSERT INTO t0 VALUES (?);]], {50.5})
would be okay, result = 50.

Re "integer 2^60-1":
Currently I can say:
box.execute([[CREATE TABLE t (s1 DOUBLE PRIMARY KEY);]])
box.execute([[INSERT INTO t VALUES (?);]], 2^60 - 1)
and is okay today, result = 2^60 - 1 (I think).

I suggest the rules that were discussed earlier:
Loss of significant digits (overflow) is a runtime error.
Loss of insignificant digits is not an error.
I think this should be possible because explicit casts work:
box.execute([[SELECT CAST(? AS INTEGER);]],{2^64}) -- result = error
box.execute([[SELECT CAST(50.5 AS INTEGER);]]) -- result = 50

 > The second question is about type mismatch error text.
 >
 > We currently have two types of type mismatch errors.
 >
 > The first:
 > - 'Type mismatch: can not convert some_text to integer'
 >
 > The second:
 > - 'Type mismatch: can not convert text to integer'
 >
 > In the first case, we use the value in the error description, in
 > the second we use the type.
 >
 > Now we have decided on the same opinion.
 >
 > We have 3 options:
 > 1) use value in error description:
 > Type mismatch: can not convert 'some_text' to integer
 > 2) use type in error description:
 > Type mismatch: can not convert text to integer
 > 3) use both in error description:
 > Type mismatch: can not convert 'some_text'(text) to integer
 >
 > The first and third options look a little unsafe, since the values
 > ​​will be shown in the logs. However, they provide more information
 > than the second option.
 >
 > Which one do you think is the best? Or maybe you can offer another
 > option?
 >
 > In addition, we must remember that at some point the description
 > becomes the same as in Lua (issue #5074):
 > 'Tuple field 1 type does not match one required by operation:
 > expected integer'
 >

Re 'Type mismatch: can not convert text to integer':

You use "type", but that is not as specific as it could be.
Why not "data type"?

You use "can not", but in other error messages
I see "cannot", for example
"cannot create trigger on system table" (trigger.c)
Why be inconsistent?

You use "text", but that is a synonym, not what typeof() returns.
Why not "string"?

You use "convert", but look at the title of this email thread.
Why not "implicitly cast"?
Actually "conversion" is better now, it is in the manual.
But I could change the manual if people wanted "cast".

Re 'Type mismatch: can not convert some_text to integer'

I do not know what your plan is, when some_text is extremely
long, or when the value has non-displayable bytes / characters.

I do not know what your plan is, when the source is not
is not a literal value, but instead is ? or is a
column name or is a function result. I guess the answer
is still "the value", but I might be confused if the
error message mentions the value but the value does not
appear in the SQL statement.

You are concentrating on making it clear what the source is.
Why not make it clear what the target is?

I think that the other way to be clear about the problem is:
return the character number of the token that is bad.
But that is not a request about the message content.

Re 'Type mismatch: can not convert 'some_text'(text) to integer'

To a beginner this is helpful, to an experienced user it
is redundant. I will guess that most users, after only a
few days, will have enough experience that they know a
literal inside single quotes is a string. So the question is:
is this so obvious that it is irritating?
I guess not.
So I like this option.

Of course I also like some texts in the SQL standard document,
"data exception -- numeric value out of range" and
"data exception -- invalid character value for cast",
but I don't like them so much that I want to fight about them.

Peter Gulutzan