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 3A84D41C5DA for ; Thu, 25 Jun 2020 11:02:10 +0300 (MSK) References: <94708d29-e20d-2d2c-9c8f-67471d972661@tarantool.org> <8770c30c-b8f4-b9f5-e472-be9a967dc251@tarantool.org> <864ee43e-70d7-df03-02a8-882dcc4e6563@ocelot.ca> From: Mergen Imeev Message-ID: Date: Thu, 25 Jun 2020 11:02:07 +0300 MIME-Version: 1.0 In-Reply-To: <864ee43e-70d7-df03-02a8-882dcc4e6563@ocelot.ca> 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 23.06.2020 22:42, Peter Gulutzan wrote: > Hi, > > On 2020-06-23 10:15 a.m., Mergen Imeev wrote: > > > 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; > > > In the SQL-standard equivalent of LIMIT n, > which is FETCH FIRST n ROWS, that is a syntax > error because > "The declared type of > shall be an exact numeric with scale 0 (zero)." > For us it is a runtime error ... Should we generate a syntax error here instead of a runtime error? However, in this case, we will not be able to execute something like this: SELECT * FROM t LIMIT 1 + 2; I will fill an issue if you think so. Actually, generating an error here seems less painful than making an integer from a double. > " > tarantool> n = 0.000000001 > --- > ... > tarantool> box.execute([[SELECT 5 LIMIT ?;]], {n}) > --- > - null > - 'Failed to execute SQL statement: Only positive >   integers are allowed in the LIMIT >   clause' > ... > " > and you are proposing that there should be no error. No, I think the error should be here. However, I'm not sure, so I asked you. > On the other hand, > box.execute([[CREATE TABLE t (s1 VARCHAR(2.0) PRIMARY KEY);]]) > causes a "Syntax error", and you are not proposing > that we change that. > Another case is > box.execute([[SELECT SUBSTR('abcde',2.99);]]) > which is legal, 2.99 is truncated to 2. I think this is worth fixing. Or is it better the way it is now? > > Therefore, I think your proposal means: > If n is not an integer, > and that is not detected as a syntax error, > then there should be no error or warning. > And I think the precedent of substr() means: > there should be truncation not rounding. > > If I have understood correctly, then I agree. > > Peter Gulutzan > >