From: Nikita Pettik <korablev@tarantool.org>
To: tarantool-patches@dev.tarantool.org
Cc: v.shpilevoy@tarantool.org
Subject: [Tarantool-patches] [PATCH 4/4] sql: do not force FP representation for NUMBER field
Date: Wed, 5 Feb 2020 19:19:12 +0300 [thread overview]
Message-ID: <80556fbc35ddc9984b63bf2560a3c666ac114516.1580841722.git.korablev@tarantool.org> (raw)
In-Reply-To: <cover.1580841722.git.korablev@tarantool.org>
In-Reply-To: <cover.1580841722.git.korablev@tarantool.org>
During value decoding fetched from space's field FP representation was
forced in case type of field was NUMBER. It was so since NUMBER used to
substitute DOUBLE field type (in fact NUMBER mimicked DOUBLE type). Since
now DOUBLE is a separate field type, there's no such necessity. Hence from
now integers from NUMBER field are treated as integers.
Implemented by Mergen Imeev <imeevma@gmail.com>
Closes #4233
@TarantoolBot document
Title: NUMBER column type changes
From now NUMBER behaves in the same way as in NoSQL Tarantool.
Previously, NUMBER was rather synonym to what now DOUBLE means: it used
to force floating point representation of values, even if they were
integers. A few examples:
1) CAST operation:
Obsolete behaviour:
SELECT CAST(922337206854774800 AS NUMBER), CAST(5 AS NUMBER) / 10;
---
rows:
- [922337206854774784, 0.5]
New behaviour:
SELECT CAST(922337206854774800 AS NUMBER), CAST(5 AS NUMBER) / 10;
---
rows:
- [922337206854774800, 0]
2) Preserving integer representation:
Obsolete behaviour:
CREATE TABLE t (n NUMBER PRIMARY KEY);
INSERT INTO t VALUES (3), (-4), (5.0);
SELECT n, n/10 FROM t;
---
rows:
- [-4, -0.4]
- [3, 0.3]
- [5, 0.5]
New behaviour:
SELECT n, n/10 FROM t;
---
rows:
- [-4, 0]
- [3, 0]
- [5, 0.5]
---
src/box/sql/vdbe.c | 8 -----
test/sql-tap/numcast.test.lua | 62 +++++++++++++++++++++++++++++++++++-
test/sql-tap/sort.test.lua | 12 +++----
test/sql-tap/tkt-91e2e8ba6f.test.lua | 12 +++----
test/sql/integer-overflow.result | 2 +-
5 files changed, 74 insertions(+), 22 deletions(-)
diff --git a/src/box/sql/vdbe.c b/src/box/sql/vdbe.c
index a5f161d90..620d74e66 100644
--- a/src/box/sql/vdbe.c
+++ b/src/box/sql/vdbe.c
@@ -2721,14 +2721,6 @@ case OP_Column: {
default_val_mem != NULL) {
sqlVdbeMemShallowCopy(pDest, default_val_mem, MEM_Static);
}
- if ((pDest->flags & (MEM_Int | MEM_UInt)) != 0) {
- if (field_type == FIELD_TYPE_NUMBER) {
- if ((pDest->flags & MEM_Int) != 0)
- sqlVdbeMemSetDouble(pDest, pDest->u.i);
- else
- sqlVdbeMemSetDouble(pDest, pDest->u.u);
- }
- }
pDest->field_type = field_type;
op_column_out:
REGISTER_TRACE(p, pOp->p3, pDest);
diff --git a/test/sql-tap/numcast.test.lua b/test/sql-tap/numcast.test.lua
index 87c5f6b35..f795cef75 100755
--- a/test/sql-tap/numcast.test.lua
+++ b/test/sql-tap/numcast.test.lua
@@ -1,6 +1,6 @@
#!/usr/bin/env tarantool
test = require("sqltester")
-test:plan(25)
+test:plan(31)
--!./tcltestrunner.lua
-- 2013 March 20
@@ -191,4 +191,64 @@ test:do_execsql_test(
10, 10
})
+test:do_execsql_test(
+ "numcast-3.6",
+ [[
+ CREATE TABLE t1 (id INT PRIMARY KEY, n NUMBER);
+ INSERT INTO t1 VALUES (1, 9223372036854775807);
+ INSERT INTO t1 VALUES (2, -9223372036854775807);
+ INSERT INTO t1 VALUES (3, 9223372036854775807.1);
+ SELECT n, n/100 FROM t1;
+ ]], {
+ 9223372036854775807ULL, 92233720368547758ULL,
+ -9223372036854775807LL, -92233720368547758LL,
+ 9223372036854775808, 92233720368547758.08
+ })
+
+test:do_execsql_test(
+ "numcast-3.7",
+ [[
+ CREATE TABLE t2(a NUMBER primary key);
+ INSERT INTO t2 VALUES(-56);
+ INSERT INTO t2 VALUES(44.0);
+ INSERT INTO t2 VALUES(46);
+ INSERT INTO t2 VALUES(56.0);
+ SELECT (a + 25) / 50 FROM t2;
+ ]], {
+ 0,1.38,1,1.62
+})
+
+
+test:do_execsql_test(
+ "numcast-3.8",
+ [[
+ SELECT (1 + 0) / 3, (1 + 0.) / 3, (1 + 0) / 3.;
+ ]], {
+ 0, 0.33333333333333, 0.33333333333333
+})
+
+test:do_execsql_test(
+ "numcast-3.9",
+ [[
+ SELECT (1 - 0) / 3, (1 - 0.) / 3, (1 - 0) / 3.;
+ ]], {
+ 0, 0.33333333333333, 0.33333333333333
+})
+
+test:do_execsql_test(
+ "numcast-3.10",
+ [[
+ SELECT (1 * 1) / 3, (1 * 1.) / 3, (1 * 1) / 3.;
+ ]], {
+ 0, 0.33333333333333, 0.33333333333333
+})
+
+test:do_execsql_test(
+ "numcast-3.11",
+ [[
+ SELECT (1 / 1) / 3, (1 / 1.) / 3, (1 / 1) / 3.;
+ ]], {
+ 0 , 0.33333333333333, 0.33333333333333
+})
+
test:finish_test()
diff --git a/test/sql-tap/sort.test.lua b/test/sql-tap/sort.test.lua
index e15641415..36074d6ef 100755
--- a/test/sql-tap/sort.test.lua
+++ b/test/sql-tap/sort.test.lua
@@ -243,7 +243,7 @@ test:do_execsql_test(
SELECT v FROM t1 ORDER BY v;
]], {
-- <sort-2.1.1>
- "x-123.0", "x-2.15", "x-2b", "x-3.141592653", "x-4221.0", "x0.0013442", "x1.6", "x11.0"
+ "x-123.0", "x-2.15", "x-2b", "x-3.141592653", "x-4221.0", "x0.0013442", "x1.6", "x11"
-- </sort-2.1.1>
})
@@ -253,7 +253,7 @@ test:do_execsql_test(
SELECT v FROM t1 ORDER BY substr(v,2,999);
]], {
-- <sort-2.1.2>
- "x-123.0", "x-2.15", "x-2b", "x-3.141592653", "x-4221.0", "x0.0013442", "x1.6", "x11.0"
+ "x-123.0", "x-2.15", "x-2b", "x-3.141592653", "x-4221.0", "x0.0013442", "x1.6", "x11"
-- </sort-2.1.2>
})
@@ -263,7 +263,7 @@ test:do_execsql_test(
SELECT v FROM t1 ORDER BY substr(v,2,999) DESC;
]], {
-- <sort-2.1.4>
- "x11.0", "x1.6", "x0.0013442", "x-4221.0", "x-3.141592653", "x-2b", "x-2.15", "x-123.0"
+ "x11", "x1.6", "x0.0013442", "x-4221.0", "x-3.141592653", "x-2b", "x-2.15", "x-123.0"
-- </sort-2.1.4>
})
@@ -381,7 +381,7 @@ test:do_execsql_test(
SELECT v FROM t1 ORDER BY 1;
]], {
-- <sort-4.6>
- "x-123.0", "x-2.15", "x-2b", "x-3.141592653", "x-4.0e9", "x-4221.0", "x0.0013442", "x01234567890123456789", "x1.6", "x11.0", "x2.7", "x5.0e10"
+ "x-123.0", "x-2.15", "x-2b", "x-3.141592653", "x-4.0e9", "x-4221.0", "x0.0013442", "x01234567890123456789", "x1.6", "x11", "x2.7", "x5.0e10"
-- </sort-4.6>
})
@@ -391,7 +391,7 @@ test:do_execsql_test(
SELECT v FROM t1 ORDER BY 1 DESC;
]], {
-- <sort-4.7>
- "x5.0e10", "x2.7", "x11.0", "x1.6", "x01234567890123456789", "x0.0013442", "x-4221.0", "x-4.0e9", "x-3.141592653", "x-2b", "x-2.15", "x-123.0"
+ "x5.0e10", "x2.7", "x11", "x1.6", "x01234567890123456789", "x0.0013442", "x-4221.0", "x-4.0e9", "x-3.141592653", "x-2b", "x-2.15", "x-123.0"
-- </sort-4.7>
})
@@ -401,7 +401,7 @@ test:do_execsql_test(
SELECT substr(v,2,99) FROM t1 ORDER BY 1;
]], {
-- <sort-4.8>
- "-123.0","-2.15","-2b","-3.141592653","-4.0e9","-4221.0","0.0013442","01234567890123456789","1.6","11.0","2.7","5.0e10"
+ "-123.0","-2.15","-2b","-3.141592653","-4.0e9","-4221.0","0.0013442","01234567890123456789","1.6","11","2.7","5.0e10"
-- </sort-4.8>
})
diff --git a/test/sql-tap/tkt-91e2e8ba6f.test.lua b/test/sql-tap/tkt-91e2e8ba6f.test.lua
index 7622f7536..b12b6e0f3 100755
--- a/test/sql-tap/tkt-91e2e8ba6f.test.lua
+++ b/test/sql-tap/tkt-91e2e8ba6f.test.lua
@@ -35,7 +35,7 @@ test:do_execsql_test(
SELECT x/10, y/10 FROM t1;
]], {
-- <1.2>
- 1, 1.1
+ 1, 1
-- </1.2>
})
@@ -45,7 +45,7 @@ test:do_execsql_test(
SELECT x/10, y/10 FROM (SELECT * FROM t1);
]], {
-- <1.3>
- 1, 1.1
+ 1, 1
-- </1.3>
})
@@ -55,7 +55,7 @@ test:do_execsql_test(
SELECT x/10, y/10 FROM (SELECT * FROM t1 LIMIT 5 OFFSET 0);
]], {
-- <1.4>
- 1, 1.1
+ 1, 1
-- </1.4>
})
@@ -65,7 +65,7 @@ test:do_execsql_test(
SELECT x/10, y/10 FROM (SELECT * FROM t1 LIMIT 5 OFFSET 0) LIMIT 5 OFFSET 0;
]], {
-- <1.5>
- 1, 1.1
+ 1, 1
-- </1.5>
})
@@ -77,7 +77,7 @@ test:do_execsql_test(
LIMIT 5 OFFSET 0;
]], {
-- <1.6>
- 1, 1.1
+ 1, 1
-- </1.6>
})
@@ -92,7 +92,7 @@ test:do_execsql_test(
SELECT a.x/10, a.y/10 FROM v1 AS a, t1 AS b WHERE a.x = b.x LIMIT 5 OFFSET 0;
]], {
-- <1.7>
- 1, 1.1
+ 1, 1
-- </1.7>
})
diff --git a/test/sql/integer-overflow.result b/test/sql/integer-overflow.result
index db5c2f725..6269cb547 100644
--- a/test/sql/integer-overflow.result
+++ b/test/sql/integer-overflow.result
@@ -170,7 +170,7 @@ box.execute("SELECT * FROM t;")
- name: A
type: number
rows:
- - [1, 1.844674407371e+19]
+ - [1, 18446744073709551615]
- [2, -1]
...
box.space.T:drop()
--
2.15.1
next prev parent reply other threads:[~2020-02-05 16:19 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-05 16:19 [Tarantool-patches] [PATCH 0/4] sql: fix NUMBER conversion issues Nikita Pettik
2020-02-05 16:19 ` [Tarantool-patches] [PATCH 1/4] sql: remove cast to INT during FP arithmetic ops Nikita Pettik
2020-02-05 16:19 ` [Tarantool-patches] [PATCH 2/4] sql: refactor sqlVdbeMemNumerify() Nikita Pettik
2020-02-10 23:25 ` Vladislav Shpilevoy
2020-02-11 14:14 ` Nikita Pettik
2020-02-11 22:17 ` Vladislav Shpilevoy
2020-02-05 16:19 ` [Tarantool-patches] [PATCH 3/4] sql: fix CAST AS NUMBER operator Nikita Pettik
2020-02-10 23:24 ` Vladislav Shpilevoy
2020-02-11 14:14 ` Nikita Pettik
2020-02-11 22:17 ` Vladislav Shpilevoy
2020-02-11 23:20 ` Nikita Pettik
2020-02-11 23:27 ` Vladislav Shpilevoy
2020-02-12 14:10 ` Nikita Pettik
2020-02-05 16:19 ` Nikita Pettik [this message]
2020-02-10 23:24 ` [Tarantool-patches] [PATCH 4/4] sql: do not force FP representation for NUMBER field Vladislav Shpilevoy
2020-02-11 14:14 ` Nikita Pettik
2020-02-09 17:39 ` [Tarantool-patches] [PATCH 0/4] sql: fix NUMBER conversion issues Vladislav Shpilevoy
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=80556fbc35ddc9984b63bf2560a3c666ac114516.1580841722.git.korablev@tarantool.org \
--to=korablev@tarantool.org \
--cc=tarantool-patches@dev.tarantool.org \
--cc=v.shpilevoy@tarantool.org \
--subject='Re: [Tarantool-patches] [PATCH 4/4] sql: do not force FP representation for NUMBER field' \
/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