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

[Mergen Imeev <imeevma@tarantool.org>]

Hi,

On 23.06.2020 22:42, Peter Gulutzan wrote:
> 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 ...
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
>
>