From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <pgulutzan@ocelot.ca>
Received: from rhino.ch-server.com (rhino.ch-server.com [209.59.190.103])
 (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 6608F42F4AD
 for <tarantool-discussions@dev.tarantool.org>;
 Tue, 23 Jun 2020 22:42:10 +0300 (MSK)
References: <94708d29-e20d-2d2c-9c8f-67471d972661@tarantool.org>
 <cc824f73-737e-cdb1-5901-9c606ad34241@ocelot.ca>
 <8770c30c-b8f4-b9f5-e472-be9a967dc251@tarantool.org>
From: Peter Gulutzan <pgulutzan@ocelot.ca>
Message-ID: <864ee43e-70d7-df03-02a8-882dcc4e6563@ocelot.ca>
Date: Tue, 23 Jun 2020 13:42:06 -0600
MIME-Version: 1.0
In-Reply-To: <8770c30c-b8f4-b9f5-e472-be9a967dc251@tarantool.org>
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
 <tarantool-discussions.dev.tarantool.org>
List-Unsubscribe: <https://lists.tarantool.org/mailman/options/tarantool-discussions>, 
 <mailto:tarantool-discussions-request@dev.tarantool.org?subject=unsubscribe>
List-Archive: <https://lists.tarantool.org/pipermail/tarantool-discussions/>
List-Post: <mailto:tarantool-discussions@dev.tarantool.org>
List-Help: <mailto:tarantool-discussions-request@dev.tarantool.org?subject=help>
List-Subscribe: <https://lists.tarantool.org/mailman/listinfo/tarantool-discussions>, 
 <mailto:tarantool-discussions-request@dev.tarantool.org?subject=subscribe>
To: Mergen Imeev <imeevma@tarantool.org>, tarantool-discussions@dev.tarantool.org, korablev@tarantool.org, Vladislav Shpilevoy <v.shpilevoy@tarantool.org>, tsafin@tarantool.org

Hi,

On 2020-06-23 10:15 a.m., Mergen Imeev wrote:
<cut>
 > 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;
<cut>

In the SQL-standard equivalent of LIMIT n,
which is FETCH FIRST n ROWS, that is a syntax
error because
"The declared type of <fetch first row count>
shall be an exact numeric with scale 0 (zero)."
For us it is a runtime error ...
"
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.
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.

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