Fixed.commit 53a229c67b096a09f26df4b5ba73d9a90c46e38f Author: Mergen Imeev <imeevma@gmail.com> Date: Thu Sep 27 22:42:29 2018 +0300 sql: assertion in autoincrement column If query is like "INSERT INTO table SELECT ..." then it is completely fine that the result of SELECT isn't integer. This value wasn't cheched propertly if it was inserted in columnNit: cheched? propertly? Correct version I guess should be: ’This values wouldn’t be checked properly if it was inserted ...'
That is not right. For example (it is current test actually):with autoincrement. Closes #3670 diff --git a/src/box/sql/vdbe.c b/src/box/sql/vdbe.c index 7c1015c..de18262 100644 --- a/src/box/sql/vdbe.c +++ b/src/box/sql/vdbe.c @@ -3736,10 +3736,15 @@ case OP_FCopy: { /* out2 */ /* Flag is set and register is NULL -> do nothing */ } else { assert(memIsValid(pIn1)); - assert(pIn1->flags & MEM_Int); pOut = &aMem[pOp->p2]; - MemSetTypeFlag(pOut, MEM_Int); + /* + * If query is like "INSERT INTO table SELECT ..." + * then it is possible then the result of SELECT + * isn't MEM_Int. It will be checked later in + * current VDBE. + */How OP_FCopy is related to this ticket? Comment to this opcodes clearly says: * Copy integer value of register P1 in root frame in to register P2 of current * frame Mb you need to fix code generation for that query, but I doubt even that. AFAIU initial problem lies in ticket #3735. Due to this behaviour (converting INT to FLOAT for overflowed integers) we are trying to insert wrong value to source table. Hence, this patch is likely to be useless.
Removed this test and added commented issue 3735+ MemSetTypeFlag(pOut, pIn1->flags); pOut->u.i = pIn1->u.i; } diff --git a/test/sql-tap/autoinc.test.lua b/test/sql-tap/autoinc.test.lua index dda7061..bd40de9 100755 --- a/test/sql-tap/autoinc.test.lua +++ b/test/sql-tap/autoinc.test.lua @@ -1,6 +1,6 @@ #!/usr/bin/env tarantool test = require("sqltester") -test:plan(46) +test:plan(48) --!./tcltestrunner.lua -- 2004 November 12 @@ -801,4 +801,29 @@ test:do_test( -- </autoinc-a69637.2> }) +-- gh-3670: Assertion with large number in autoincrement column +test:do_catchsql_test( + "autoinc-gh-3670-1", + [[ + CREATE TABLE t0 (s1 INT PRIMARY KEY AUTOINCREMENT); + INSERT INTO t0 VALUES (2147483647); + INSERT INTO t0 SELECT max(s1)*max(s1)*max(s1) FROM t0; + ]], { + -- <autoinc-10.2> + 1, "datatype mismatch”Still: why ‘datatype mismatch’ and not ‘integer overflow’? I guess from now this test belongs to https://github.com/tarantool/tarantool/issues/3735
+ -- </autoinc-10.2> + }) + +test:do_catchsql_test( + "autoinc-gh-3670-2", + [[ + CREATE TABLE t1 (s1 INT PRIMARY KEY AUTOINCREMENT, s2 CHAR); + INSERT INTO t1 VALUES (1, 'a'); + INSERT INTO t1 SELECT s2, s2 FROM t1; + ]], { + -- <autoinc-10.2> + 1, "datatype mismatch" + -- </autoinc-10.2> + }) +