From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtpng3.m.smailru.net (smtpng3.m.smailru.net [94.100.177.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 4255E41C5DA for ; Tue, 23 Jun 2020 19:15:08 +0300 (MSK) References: <94708d29-e20d-2d2c-9c8f-67471d972661@tarantool.org> From: Mergen Imeev Message-ID: <8770c30c-b8f4-b9f5-e472-be9a967dc251@tarantool.org> Date: Tue, 23 Jun 2020 19:15:06 +0300 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format="flowed" Content-Transfer-Encoding: 8bit Content-Language: en-US Subject: Re: [Tarantool-discussions] Implicit cast for assignment between numeric types and type mismatch error description. List-Id: Tarantool development process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Gulutzan , tarantool-discussions@dev.tarantool.org, korablev@tarantool.org, Vladislav Shpilevoy , tsafin@tarantool.org Hi! On 22.06.2020 21:43, Peter Gulutzan wrote: > 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 > Thanks for the answer. However, I now have another question: should we apply these rules for cases like this: SELECT * FROM t LIMIT 2.5; I mean, we should throw an error here or execute it like this: SELECT * FROM t LIMIT 2; > > 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 >