From: Mergen Imeev <imeevma@tarantool.org> To: Peter Gulutzan <pgulutzan@ocelot.ca>, tarantool-discussions@dev.tarantool.org, korablev@tarantool.org, Vladislav Shpilevoy <v.shpilevoy@tarantool.org>, tsafin@tarantool.org Subject: Re: [Tarantool-discussions] Implicit cast for assignment between numeric types and type mismatch error description. Date: Tue, 23 Jun 2020 19:15:06 +0300 [thread overview] Message-ID: <8770c30c-b8f4-b9f5-e472-be9a967dc251@tarantool.org> (raw) In-Reply-To: <cc824f73-737e-cdb1-5901-9c606ad34241@ocelot.ca> 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 >
next prev parent reply other threads:[~2020-06-23 16:15 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-06-22 11:52 Mergen Imeev 2020-06-22 18:43 ` Peter Gulutzan 2020-06-23 16:15 ` Mergen Imeev [this message] 2020-06-23 19:42 ` Peter Gulutzan 2020-06-25 8:02 ` Mergen Imeev 2020-06-25 19:39 ` Peter Gulutzan
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=8770c30c-b8f4-b9f5-e472-be9a967dc251@tarantool.org \ --to=imeevma@tarantool.org \ --cc=korablev@tarantool.org \ --cc=pgulutzan@ocelot.ca \ --cc=tarantool-discussions@dev.tarantool.org \ --cc=tsafin@tarantool.org \ --cc=v.shpilevoy@tarantool.org \ --subject='Re: [Tarantool-discussions] Implicit cast for assignment between numeric types and type mismatch error description.' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox