2016-12-10 22:25:17 +04:00
SET SESSION debug_dbug="+d,Item_func_in";
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
SET SESSION debug_dbug="+d,Predicant_to_list_comparator";
2016-12-10 22:25:17 +04:00
# Constant predicant, compatible types, bisect
SELECT 1 IN (1,2);
1 IN (1,2)
1
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=0 (bigint)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT 1 IN (1,2,NULL);
1 IN (1,2,NULL)
1
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=0 (bigint)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT 1 NOT IN (1,2);
1 NOT IN (1,2)
0
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=0 (bigint)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT 1 NOT IN (1,2,NULL);
1 NOT IN (1,2,NULL)
0
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=0 (bigint)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT 1.0 IN (1.0,2.0);
1.0 IN (1.0,2.0)
1
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=0 (decimal)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT 1.0 IN (1.0,2.0,NULL);
1.0 IN (1.0,2.0,NULL)
1
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=0 (decimal)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT 1.0 NOT IN (1.0,2.0);
1.0 NOT IN (1.0,2.0)
0
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=0 (decimal)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT 1.0 NOT IN (1.0,2.0,NULL);
1.0 NOT IN (1.0,2.0,NULL)
0
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=0 (decimal)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT 1e0 IN (1e0,2e0);
1e0 IN (1e0,2e0)
1
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (double)
Note 1105 DBUG: [1] arg=2 handler=0 (double)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT 1e0 IN (1e0,2e0,NULL);
1e0 IN (1e0,2e0,NULL)
1
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (double)
Note 1105 DBUG: [1] arg=2 handler=0 (double)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT 1e0 NOT IN (1e0,2e0);
1e0 NOT IN (1e0,2e0)
0
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (double)
Note 1105 DBUG: [1] arg=2 handler=0 (double)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT 1e0 NOT IN (1e0,2e0,NULL);
1e0 NOT IN (1e0,2e0,NULL)
0
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (double)
Note 1105 DBUG: [1] arg=2 handler=0 (double)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT 'a' IN ('a','b');
'a' IN ('a','b')
1
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (longblob)
Note 1105 DBUG: [1] arg=2 handler=0 (longblob)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT 'a' IN ('a','b',NULL);
'a' IN ('a','b',NULL)
1
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (longblob)
Note 1105 DBUG: [1] arg=2 handler=0 (longblob)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT 'a' NOT IN ('a','b');
'a' NOT IN ('a','b')
0
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (longblob)
Note 1105 DBUG: [1] arg=2 handler=0 (longblob)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT 'a' NOT IN ('a','b',NULL);
'a' NOT IN ('a','b',NULL)
0
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (longblob)
Note 1105 DBUG: [1] arg=2 handler=0 (longblob)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT TIMESTAMP'2001-01-01 10:20:30' IN ('2001-01-01 10:20:30','2001-02-02 10:20:30');
TIMESTAMP'2001-01-01 10:20:30' IN ('2001-01-01 10:20:30','2001-02-02 10:20:30')
1
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (datetime)
Note 1105 DBUG: [1] arg=2 handler=0 (datetime)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT TIMESTAMP'2001-01-01 10:20:30' IN ('2001-01-01 10:20:30','2001-02-02 10:20:30',NULL);
TIMESTAMP'2001-01-01 10:20:30' IN ('2001-01-01 10:20:30','2001-02-02 10:20:30',NULL)
1
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (datetime)
Note 1105 DBUG: [1] arg=2 handler=0 (datetime)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT TIMESTAMP'2001-01-01 10:20:30' NOT IN ('2001-01-01 10:20:30','2001-02-02 10:20:30');
TIMESTAMP'2001-01-01 10:20:30' NOT IN ('2001-01-01 10:20:30','2001-02-02 10:20:30')
0
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (datetime)
Note 1105 DBUG: [1] arg=2 handler=0 (datetime)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT TIMESTAMP'2001-01-01 10:20:30' NOT IN ('2001-01-01 10:20:30','2001-02-02 10:20:30',NULL);
TIMESTAMP'2001-01-01 10:20:30' NOT IN ('2001-01-01 10:20:30','2001-02-02 10:20:30',NULL)
0
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (datetime)
Note 1105 DBUG: [1] arg=2 handler=0 (datetime)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT TIME'10:20:30' IN ('10:20:30','10:20:30');
TIME'10:20:30' IN ('10:20:30','10:20:30')
1
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (time)
Note 1105 DBUG: [1] arg=2 handler=0 (time)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT TIME'10:20:30' IN ('10:20:30','10:20:30',NULL);
TIME'10:20:30' IN ('10:20:30','10:20:30',NULL)
1
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (time)
Note 1105 DBUG: [1] arg=2 handler=0 (time)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT TIME'10:20:30' NOT IN ('10:20:30','10:20:30');
TIME'10:20:30' NOT IN ('10:20:30','10:20:30')
0
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (time)
Note 1105 DBUG: [1] arg=2 handler=0 (time)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT TIME'10:20:30' NOT IN ('10:20:30','10:20:30',NULL);
TIME'10:20:30' NOT IN ('10:20:30','10:20:30',NULL)
0
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (time)
Note 1105 DBUG: [1] arg=2 handler=0 (time)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT DATE'2001-01-01' IN ('2001-01-01','2001-02-02');
DATE'2001-01-01' IN ('2001-01-01','2001-02-02')
1
Warnings:
2017-05-06 00:04:15 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (date)
Note 1105 DBUG: [1] arg=2 handler=0 (date)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT DATE'2001-01-01' IN ('2001-01-01','2001-02-02',NULL);
DATE'2001-01-01' IN ('2001-01-01','2001-02-02',NULL)
1
Warnings:
2017-05-06 00:04:15 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (date)
Note 1105 DBUG: [1] arg=2 handler=0 (date)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT DATE'2001-01-01' NOT IN ('2001-01-01','2001-02-02');
DATE'2001-01-01' NOT IN ('2001-01-01','2001-02-02')
0
Warnings:
2017-05-06 00:04:15 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (date)
Note 1105 DBUG: [1] arg=2 handler=0 (date)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT DATE'2001-01-01' NOT IN ('2001-01-01','2001-02-02',NULL);
DATE'2001-01-01' NOT IN ('2001-01-01','2001-02-02',NULL)
0
Warnings:
2017-05-06 00:04:15 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (date)
Note 1105 DBUG: [1] arg=2 handler=0 (date)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
# Column predicant, compatible types, bisect
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
CREATE TABLE t1 (a INT UNSIGNED);
SELECT a IN (1.0, 1) FROM t1;
a IN (1.0, 1)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=0 (decimal)
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
DROP TABLE t1;
2016-12-10 22:25:17 +04:00
CREATE TABLE t1 (a INT);
SELECT a IN (1,2,3) FROM t1;
a IN (1,2,3)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=0 (bigint)
Note 1105 DBUG: [2] arg=3 handler=0 (bigint)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT a IN (1,2,3,NULL) FROM t1;
a IN (1,2,3,NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=0 (bigint)
Note 1105 DBUG: [2] arg=3 handler=0 (bigint)
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
SELECT a IN (1.0, CAST(1 AS UNSIGNED)) FROM t1;
a IN (1.0, CAST(1 AS UNSIGNED))
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=0 (decimal)
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
SELECT a IN (1.0, CAST(1 AS UNSIGNED),NULL) FROM t1;
a IN (1.0, CAST(1 AS UNSIGNED),NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=0 (decimal)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT a NOT IN (1,2,3) FROM t1;
a NOT IN (1,2,3)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=0 (bigint)
Note 1105 DBUG: [2] arg=3 handler=0 (bigint)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT a NOT IN (1,2,3,NULL) FROM t1;
a NOT IN (1,2,3,NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=0 (bigint)
Note 1105 DBUG: [2] arg=3 handler=0 (bigint)
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
SELECT a NOT IN (1.0, CAST(1 AS UNSIGNED)) FROM t1;
a NOT IN (1.0, CAST(1 AS UNSIGNED))
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=0 (decimal)
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
SELECT a NOT IN (1.0, CAST(1 AS UNSIGNED),NULL) FROM t1;
a NOT IN (1.0, CAST(1 AS UNSIGNED),NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=0 (decimal)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
DROP TABLE t1;
CREATE TABLE t1 (a DOUBLE);
SELECT a IN (1e0,2,3.0) FROM t1;
a IN (1e0,2,3.0)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (double)
Note 1105 DBUG: [1] arg=2 handler=0 (double)
Note 1105 DBUG: [2] arg=3 handler=0 (double)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT a IN (1e0,2,3.0,NULL) FROM t1;
a IN (1e0,2,3.0,NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (double)
Note 1105 DBUG: [1] arg=2 handler=0 (double)
Note 1105 DBUG: [2] arg=3 handler=0 (double)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT a NOT IN (1e0,2,3.0) FROM t1;
a NOT IN (1e0,2,3.0)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (double)
Note 1105 DBUG: [1] arg=2 handler=0 (double)
Note 1105 DBUG: [2] arg=3 handler=0 (double)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT a NOT IN (1e0,2,3.0,NULL) FROM t1;
a NOT IN (1e0,2,3.0,NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (double)
Note 1105 DBUG: [1] arg=2 handler=0 (double)
Note 1105 DBUG: [2] arg=3 handler=0 (double)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
DROP TABLE t1;
CREATE TABLE t1 (a DECIMAL(10,1));
SELECT a IN (1,2.0,3.0) FROM t1;
a IN (1,2.0,3.0)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=0 (decimal)
Note 1105 DBUG: [2] arg=3 handler=0 (decimal)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT a IN (1,2.0,3.0,NULL) FROM t1;
a IN (1,2.0,3.0,NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=0 (decimal)
Note 1105 DBUG: [2] arg=3 handler=0 (decimal)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT a NOT IN (1,2.0,3.0) FROM t1;
a NOT IN (1,2.0,3.0)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=0 (decimal)
Note 1105 DBUG: [2] arg=3 handler=0 (decimal)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT a NOT IN (1,2.0,3.0,NULL) FROM t1;
a NOT IN (1,2.0,3.0,NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=0 (decimal)
Note 1105 DBUG: [2] arg=3 handler=0 (decimal)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
DROP TABLE t1;
CREATE TABLE t1 (a VARCHAR(10));
SELECT a IN ('a','b','c') FROM t1;
a IN ('a','b','c')
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (longblob)
Note 1105 DBUG: [1] arg=2 handler=0 (longblob)
Note 1105 DBUG: [2] arg=3 handler=0 (longblob)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT a IN ('a','b','c',NULL) FROM t1;
a IN ('a','b','c',NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (longblob)
Note 1105 DBUG: [1] arg=2 handler=0 (longblob)
Note 1105 DBUG: [2] arg=3 handler=0 (longblob)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT a NOT IN ('a','b','c') FROM t1;
a NOT IN ('a','b','c')
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (longblob)
Note 1105 DBUG: [1] arg=2 handler=0 (longblob)
Note 1105 DBUG: [2] arg=3 handler=0 (longblob)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT a NOT IN ('a','b','c',NULL) FROM t1;
a NOT IN ('a','b','c',NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (longblob)
Note 1105 DBUG: [1] arg=2 handler=0 (longblob)
Note 1105 DBUG: [2] arg=3 handler=0 (longblob)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
DROP TABLE t1;
CREATE TABLE t1 (a DATE);
SELECT a IN ('2001-01-01',DATE'2001-01-02',20010102,20010102.0,20010102e0) FROM t1;
a IN ('2001-01-01',DATE'2001-01-02',20010102,20010102.0,20010102e0)
Warnings:
2017-05-06 00:04:15 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (date)
Note 1105 DBUG: [1] arg=2 handler=0 (date)
Note 1105 DBUG: [2] arg=3 handler=0 (date)
Note 1105 DBUG: [3] arg=4 handler=0 (date)
Note 1105 DBUG: [4] arg=5 handler=0 (date)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT a IN ('2001-01-01',DATE'2001-01-02',20010102,20010102.0,20010102e0,NULL) FROM t1;
a IN ('2001-01-01',DATE'2001-01-02',20010102,20010102.0,20010102e0,NULL)
Warnings:
2017-05-06 00:04:15 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (date)
Note 1105 DBUG: [1] arg=2 handler=0 (date)
Note 1105 DBUG: [2] arg=3 handler=0 (date)
Note 1105 DBUG: [3] arg=4 handler=0 (date)
Note 1105 DBUG: [4] arg=5 handler=0 (date)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT a NOT IN ('2001-01-01',DATE'2001-01-02',20010102,20010102.0,20010102e0) FROM t1;
a NOT IN ('2001-01-01',DATE'2001-01-02',20010102,20010102.0,20010102e0)
Warnings:
2017-05-06 00:04:15 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (date)
Note 1105 DBUG: [1] arg=2 handler=0 (date)
Note 1105 DBUG: [2] arg=3 handler=0 (date)
Note 1105 DBUG: [3] arg=4 handler=0 (date)
Note 1105 DBUG: [4] arg=5 handler=0 (date)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT a NOT IN ('2001-01-01',DATE'2001-01-02',20010102,20010102.0,20010102e0,NULL) FROM t1;
a NOT IN ('2001-01-01',DATE'2001-01-02',20010102,20010102.0,20010102e0,NULL)
Warnings:
2017-05-06 00:04:15 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (date)
Note 1105 DBUG: [1] arg=2 handler=0 (date)
Note 1105 DBUG: [2] arg=3 handler=0 (date)
Note 1105 DBUG: [3] arg=4 handler=0 (date)
Note 1105 DBUG: [4] arg=5 handler=0 (date)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
DROP TABLE t1;
CREATE TABLE t1 (a TIME);
SELECT a IN ('10:20:30',TIME'10:20:30',102030,102030.0,102030e0) FROM t1;
a IN ('10:20:30',TIME'10:20:30',102030,102030.0,102030e0)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (time)
Note 1105 DBUG: [1] arg=2 handler=0 (time)
Note 1105 DBUG: [2] arg=3 handler=0 (time)
Note 1105 DBUG: [3] arg=4 handler=0 (time)
Note 1105 DBUG: [4] arg=5 handler=0 (time)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT a IN ('10:20:30',TIME'10:20:30',102030,102030.0,102030e0,NULL) FROM t1;
a IN ('10:20:30',TIME'10:20:30',102030,102030.0,102030e0,NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (time)
Note 1105 DBUG: [1] arg=2 handler=0 (time)
Note 1105 DBUG: [2] arg=3 handler=0 (time)
Note 1105 DBUG: [3] arg=4 handler=0 (time)
Note 1105 DBUG: [4] arg=5 handler=0 (time)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT a NOT IN ('10:20:30',TIME'10:20:30',102030,102030.0,102030e0) FROM t1;
a NOT IN ('10:20:30',TIME'10:20:30',102030,102030.0,102030e0)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (time)
Note 1105 DBUG: [1] arg=2 handler=0 (time)
Note 1105 DBUG: [2] arg=3 handler=0 (time)
Note 1105 DBUG: [3] arg=4 handler=0 (time)
Note 1105 DBUG: [4] arg=5 handler=0 (time)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT a NOT IN ('10:20:30',TIME'10:20:30',102030,102030.0,102030e0,NULL) FROM t1;
a NOT IN ('10:20:30',TIME'10:20:30',102030,102030.0,102030e0,NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (time)
Note 1105 DBUG: [1] arg=2 handler=0 (time)
Note 1105 DBUG: [2] arg=3 handler=0 (time)
Note 1105 DBUG: [3] arg=4 handler=0 (time)
Note 1105 DBUG: [4] arg=5 handler=0 (time)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
DROP TABLE t1;
CREATE TABLE t1 (a DATETIME);
SELECT a IN ('2001-01-01',TIMESTAMP'2001-01-01 10:20:30',DATE'2001-01-01',TIME'10:20:30',20010101102030,20010101102030.0,20010101102030e0) FROM t1;
a IN ('2001-01-01',TIMESTAMP'2001-01-01 10:20:30',DATE'2001-01-01',TIME'10:20:30',20010101102030,20010101102030.0,20010101102030e0)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (datetime)
Note 1105 DBUG: [1] arg=2 handler=0 (datetime)
Note 1105 DBUG: [2] arg=3 handler=0 (datetime)
Note 1105 DBUG: [3] arg=4 handler=0 (datetime)
Note 1105 DBUG: [4] arg=5 handler=0 (datetime)
Note 1105 DBUG: [5] arg=6 handler=0 (datetime)
Note 1105 DBUG: [6] arg=7 handler=0 (datetime)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT a IN ('2001-01-01',TIMESTAMP'2001-01-01 10:20:30',DATE'2001-01-01',TIME'10:20:30',20010101102030,20010101102030.0,20010101102030e0,NULL) FROM t1;
a IN ('2001-01-01',TIMESTAMP'2001-01-01 10:20:30',DATE'2001-01-01',TIME'10:20:30',20010101102030,20010101102030.0,20010101102030e0,NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (datetime)
Note 1105 DBUG: [1] arg=2 handler=0 (datetime)
Note 1105 DBUG: [2] arg=3 handler=0 (datetime)
Note 1105 DBUG: [3] arg=4 handler=0 (datetime)
Note 1105 DBUG: [4] arg=5 handler=0 (datetime)
Note 1105 DBUG: [5] arg=6 handler=0 (datetime)
Note 1105 DBUG: [6] arg=7 handler=0 (datetime)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT a NOT IN ('2001-01-01',TIMESTAMP'2001-01-01 10:20:30',DATE'2001-01-01',TIME'10:20:30',20010101102030,20010101102030.0,20010101102030e0) FROM t1;
a NOT IN ('2001-01-01',TIMESTAMP'2001-01-01 10:20:30',DATE'2001-01-01',TIME'10:20:30',20010101102030,20010101102030.0,20010101102030e0)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (datetime)
Note 1105 DBUG: [1] arg=2 handler=0 (datetime)
Note 1105 DBUG: [2] arg=3 handler=0 (datetime)
Note 1105 DBUG: [3] arg=4 handler=0 (datetime)
Note 1105 DBUG: [4] arg=5 handler=0 (datetime)
Note 1105 DBUG: [5] arg=6 handler=0 (datetime)
Note 1105 DBUG: [6] arg=7 handler=0 (datetime)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT a NOT IN ('2001-01-01',TIMESTAMP'2001-01-01 10:20:30',DATE'2001-01-01',TIME'10:20:30',20010101102030,20010101102030.0,20010101102030e0,NULL) FROM t1;
a NOT IN ('2001-01-01',TIMESTAMP'2001-01-01 10:20:30',DATE'2001-01-01',TIME'10:20:30',20010101102030,20010101102030.0,20010101102030e0,NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (datetime)
Note 1105 DBUG: [1] arg=2 handler=0 (datetime)
Note 1105 DBUG: [2] arg=3 handler=0 (datetime)
Note 1105 DBUG: [3] arg=4 handler=0 (datetime)
Note 1105 DBUG: [4] arg=5 handler=0 (datetime)
Note 1105 DBUG: [5] arg=6 handler=0 (datetime)
Note 1105 DBUG: [6] arg=7 handler=0 (datetime)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
DROP TABLE t1;
# Constant predicant, compatible types, no bisect
# Bisect is not used because of non-constant expressions in the list
CREATE TABLE t1 (a INT);
SELECT 1 IN (a,1,2,3) FROM t1;
1 IN (a,1,2,3)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=0 (bigint)
Note 1105 DBUG: [2] arg=3 handler=0 (bigint)
Note 1105 DBUG: [3] arg=4 handler=0 (bigint)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=no
2016-12-10 22:25:17 +04:00
SELECT 1 IN (a,1,2,3,NULL) FROM t1;
1 IN (a,1,2,3,NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=0 (bigint)
Note 1105 DBUG: [2] arg=3 handler=0 (bigint)
Note 1105 DBUG: [3] arg=4 handler=0 (bigint)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=no
2016-12-10 22:25:17 +04:00
SELECT 1 NOT IN (a,1,2,3) FROM t1;
1 NOT IN (a,1,2,3)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=0 (bigint)
Note 1105 DBUG: [2] arg=3 handler=0 (bigint)
Note 1105 DBUG: [3] arg=4 handler=0 (bigint)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=no
2016-12-10 22:25:17 +04:00
SELECT 1 NOT IN (a,1,2,3,NULL) FROM t1;
1 NOT IN (a,1,2,3,NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=0 (bigint)
Note 1105 DBUG: [2] arg=3 handler=0 (bigint)
Note 1105 DBUG: [3] arg=4 handler=0 (bigint)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=no
2016-12-10 22:25:17 +04:00
DROP TABLE t1;
CREATE TABLE t1 (a DOUBLE);
SELECT 1 IN (a,1e0,2e0,3e0) FROM t1;
1 IN (a,1e0,2e0,3e0)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (double)
Note 1105 DBUG: [1] arg=2 handler=0 (double)
Note 1105 DBUG: [2] arg=3 handler=0 (double)
Note 1105 DBUG: [3] arg=4 handler=0 (double)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=no
2016-12-10 22:25:17 +04:00
SELECT 1 IN (a,1e0,2e0,3e0,NULL) FROM t1;
1 IN (a,1e0,2e0,3e0,NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (double)
Note 1105 DBUG: [1] arg=2 handler=0 (double)
Note 1105 DBUG: [2] arg=3 handler=0 (double)
Note 1105 DBUG: [3] arg=4 handler=0 (double)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=no
2016-12-10 22:25:17 +04:00
SELECT 1 NOT IN (a,1e0,2e0,3e0) FROM t1;
1 NOT IN (a,1e0,2e0,3e0)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (double)
Note 1105 DBUG: [1] arg=2 handler=0 (double)
Note 1105 DBUG: [2] arg=3 handler=0 (double)
Note 1105 DBUG: [3] arg=4 handler=0 (double)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=no
2016-12-10 22:25:17 +04:00
SELECT 1 NOT IN (a,1e0,2e0,3e0,NULL) FROM t1;
1 NOT IN (a,1e0,2e0,3e0,NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (double)
Note 1105 DBUG: [1] arg=2 handler=0 (double)
Note 1105 DBUG: [2] arg=3 handler=0 (double)
Note 1105 DBUG: [3] arg=4 handler=0 (double)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=no
2016-12-10 22:25:17 +04:00
DROP TABLE t1;
CREATE TABLE t1 (a DECIMAL(10,1));
SELECT 1 IN (a,1.0,2.0,3.0) FROM t1;
1 IN (a,1.0,2.0,3.0)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=0 (decimal)
Note 1105 DBUG: [2] arg=3 handler=0 (decimal)
Note 1105 DBUG: [3] arg=4 handler=0 (decimal)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=no
2016-12-10 22:25:17 +04:00
SELECT 1 IN (a,1.0,2.0,3.0,NULL) FROM t1;
1 IN (a,1.0,2.0,3.0,NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=0 (decimal)
Note 1105 DBUG: [2] arg=3 handler=0 (decimal)
Note 1105 DBUG: [3] arg=4 handler=0 (decimal)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=no
2016-12-10 22:25:17 +04:00
SELECT 1 NOT IN (a,1.0,2.0,3.0) FROM t1;
1 NOT IN (a,1.0,2.0,3.0)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=0 (decimal)
Note 1105 DBUG: [2] arg=3 handler=0 (decimal)
Note 1105 DBUG: [3] arg=4 handler=0 (decimal)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=no
2016-12-10 22:25:17 +04:00
SELECT 1 NOT IN (a,1.0,2.0,3.0,NULL) FROM t1;
1 NOT IN (a,1.0,2.0,3.0,NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=0 (decimal)
Note 1105 DBUG: [2] arg=3 handler=0 (decimal)
Note 1105 DBUG: [3] arg=4 handler=0 (decimal)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=no
2016-12-10 22:25:17 +04:00
DROP TABLE t1;
CREATE TABLE t1 (a VARCHAR(10));
SELECT 'a' IN (a,'b','c') FROM t1;
'a' IN (a,'b','c')
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (longblob)
Note 1105 DBUG: [1] arg=2 handler=0 (longblob)
Note 1105 DBUG: [2] arg=3 handler=0 (longblob)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=no
2016-12-10 22:25:17 +04:00
SELECT 'a' IN (a,'b','c',NULL) FROM t1;
'a' IN (a,'b','c',NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (longblob)
Note 1105 DBUG: [1] arg=2 handler=0 (longblob)
Note 1105 DBUG: [2] arg=3 handler=0 (longblob)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=no
2016-12-10 22:25:17 +04:00
SELECT 'a' NOT IN (a,'b','c') FROM t1;
'a' NOT IN (a,'b','c')
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (longblob)
Note 1105 DBUG: [1] arg=2 handler=0 (longblob)
Note 1105 DBUG: [2] arg=3 handler=0 (longblob)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=no
2016-12-10 22:25:17 +04:00
SELECT 'a' NOT IN (a,'b','c',NULL) FROM t1;
'a' NOT IN (a,'b','c',NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (longblob)
Note 1105 DBUG: [1] arg=2 handler=0 (longblob)
Note 1105 DBUG: [2] arg=3 handler=0 (longblob)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=no
2016-12-10 22:25:17 +04:00
DROP TABLE t1;
CREATE TABLE t1 (a DATE);
SELECT DATE'2001-01-01' IN (a,'2001-01-01') FROM t1;
DATE'2001-01-01' IN (a,'2001-01-01')
Warnings:
2017-05-06 00:04:15 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (date)
Note 1105 DBUG: [1] arg=2 handler=0 (date)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=no
2016-12-10 22:25:17 +04:00
SELECT DATE'2001-01-01' IN (a,'2001-01-01',NULL) FROM t1;
DATE'2001-01-01' IN (a,'2001-01-01',NULL)
Warnings:
2017-05-06 00:04:15 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (date)
Note 1105 DBUG: [1] arg=2 handler=0 (date)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=no
2016-12-10 22:25:17 +04:00
SELECT DATE'2001-01-01' NOT IN (a,'2001-01-01') FROM t1;
DATE'2001-01-01' NOT IN (a,'2001-01-01')
Warnings:
2017-05-06 00:04:15 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (date)
Note 1105 DBUG: [1] arg=2 handler=0 (date)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=no
2016-12-10 22:25:17 +04:00
SELECT DATE'2001-01-01' NOT IN (a,'2001-01-01',NULL) FROM t1;
DATE'2001-01-01' NOT IN (a,'2001-01-01',NULL)
Warnings:
2017-05-06 00:04:15 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (date)
Note 1105 DBUG: [1] arg=2 handler=0 (date)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=no
2016-12-10 22:25:17 +04:00
DROP TABLE t1;
CREATE TABLE t1 (a TIME);
SELECT TIME'10:20:30' IN (a,'10:20:30') FROM t1;
TIME'10:20:30' IN (a,'10:20:30')
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (time)
Note 1105 DBUG: [1] arg=2 handler=0 (time)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=no
2016-12-10 22:25:17 +04:00
SELECT TIME'10:20:30' IN (a,'10:20:30',NULL) FROM t1;
TIME'10:20:30' IN (a,'10:20:30',NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (time)
Note 1105 DBUG: [1] arg=2 handler=0 (time)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=no
2016-12-10 22:25:17 +04:00
SELECT TIME'10:20:30' NOT IN (a,'10:20:30') FROM t1;
TIME'10:20:30' NOT IN (a,'10:20:30')
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (time)
Note 1105 DBUG: [1] arg=2 handler=0 (time)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=no
2016-12-10 22:25:17 +04:00
SELECT TIME'10:20:30' NOT IN (a,'10:20:30',NULL) FROM t1;
TIME'10:20:30' NOT IN (a,'10:20:30',NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (time)
Note 1105 DBUG: [1] arg=2 handler=0 (time)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=no
2016-12-10 22:25:17 +04:00
DROP TABLE t1;
CREATE TABLE t1 (a DATETIME);
SELECT TIMESTAMP'2001-01-01 10:20:30' IN (a,TIMESTAMP'2001-01-01 10:20:30') FROM t1;
TIMESTAMP'2001-01-01 10:20:30' IN (a,TIMESTAMP'2001-01-01 10:20:30')
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (datetime)
Note 1105 DBUG: [1] arg=2 handler=0 (datetime)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=no
2016-12-10 22:25:17 +04:00
SELECT TIMESTAMP'2001-01-01 10:20:30' IN (a,TIMESTAMP'2001-01-01 10:20:30',NULL) FROM t1;
TIMESTAMP'2001-01-01 10:20:30' IN (a,TIMESTAMP'2001-01-01 10:20:30',NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (datetime)
Note 1105 DBUG: [1] arg=2 handler=0 (datetime)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=no
2016-12-10 22:25:17 +04:00
SELECT TIMESTAMP'2001-01-01 10:20:30' NOT IN (a,TIMESTAMP'2001-01-01 10:20:30') FROM t1;
TIMESTAMP'2001-01-01 10:20:30' NOT IN (a,TIMESTAMP'2001-01-01 10:20:30')
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (datetime)
Note 1105 DBUG: [1] arg=2 handler=0 (datetime)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=no
2016-12-10 22:25:17 +04:00
SELECT TIMESTAMP'2001-01-01 10:20:30' NOT IN (a,TIMESTAMP'2001-01-01 10:20:30',NULL) FROM t1;
TIMESTAMP'2001-01-01 10:20:30' NOT IN (a,TIMESTAMP'2001-01-01 10:20:30',NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (datetime)
Note 1105 DBUG: [1] arg=2 handler=0 (datetime)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=no
2016-12-10 22:25:17 +04:00
DROP TABLE t1;
# Constant predicant, incompatible types, no bisect
SELECT 1 IN (1,2e0);
1 IN (1,2e0)
1
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT 1 IN (1,2e0,NULL);
1 IN (1,2e0,NULL)
1
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT 1 NOT IN (1,2e0);
1 NOT IN (1,2e0)
0
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT 1 NOT IN (1,2e0,NULL);
1 NOT IN (1,2e0,NULL)
0
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT 1.0 IN (1.0,2e0);
1.0 IN (1.0,2e0)
1
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT 1.0 IN (1.0,2e0,NULL);
1.0 IN (1.0,2e0,NULL)
1
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT 1.0 NOT IN (1.0,2e0);
1.0 NOT IN (1.0,2e0)
0
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT 1.0 NOT IN (1.0,2e0,NULL);
1.0 NOT IN (1.0,2e0,NULL)
0
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT 1e0 IN (1.0,TIME'10:20:30');
1e0 IN (1.0,TIME'10:20:30')
1
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (double)
Note 1105 DBUG: [1] arg=2 handler=1 (time)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT 1e0 IN (1.0,TIME'10:20:30',NULL);
1e0 IN (1.0,TIME'10:20:30',NULL)
1
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (double)
Note 1105 DBUG: [1] arg=2 handler=1 (time)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT 1e0 NOT IN (1.0,TIME'10:20:30');
1e0 NOT IN (1.0,TIME'10:20:30')
0
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (double)
Note 1105 DBUG: [1] arg=2 handler=1 (time)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT 1e0 NOT IN (1.0,TIME'10:20:30',NULL);
1e0 NOT IN (1.0,TIME'10:20:30',NULL)
0
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (double)
Note 1105 DBUG: [1] arg=2 handler=1 (time)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT 'a' IN ('a',2);
'a' IN ('a',2)
1
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (longblob)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT 'a' IN ('a',2,NULL);
'a' IN ('a',2,NULL)
1
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (longblob)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT 'a' NOT IN ('a',2);
'a' NOT IN ('a',2)
0
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (longblob)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT 'a' NOT IN ('a',2,NULL);
'a' NOT IN ('a',2,NULL)
0
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (longblob)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
SELECT TIME'10:20:30' IN (1,TIME'10:20:30');
TIME'10:20:30' IN (1,TIME'10:20:30')
1
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (time)
Note 1105 DBUG: [1] arg=2 handler=0 (time)
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
SELECT TIME'10:20:30' IN (1,TIME'10:20:30',NULL);
TIME'10:20:30' IN (1,TIME'10:20:30',NULL)
1
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (time)
Note 1105 DBUG: [1] arg=2 handler=0 (time)
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
SELECT TIME'10:20:30' IN (102030, TIME'10:20:30',TIMESTAMP'2001-01-01 10:20:32');
TIME'10:20:30' IN (102030, TIME'10:20:30',TIMESTAMP'2001-01-01 10:20:32')
1
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (time)
Note 1105 DBUG: [1] arg=2 handler=0 (time)
Note 1105 DBUG: [2] arg=3 handler=2 (datetime)
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
SELECT TIME'10:20:30' IN (102030, TIME'10:20:30',TIMESTAMP'2001-01-01 10:20:32',NULL);
TIME'10:20:30' IN (102030, TIME'10:20:30',TIMESTAMP'2001-01-01 10:20:32',NULL)
1
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (time)
Note 1105 DBUG: [1] arg=2 handler=0 (time)
Note 1105 DBUG: [2] arg=3 handler=2 (datetime)
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
SELECT TIME'10:20:30' IN (102030, 102030, TIME'10:20:30',TIMESTAMP'2001-01-01 10:20:32');
TIME'10:20:30' IN (102030, 102030, TIME'10:20:30',TIMESTAMP'2001-01-01 10:20:32')
1
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (time)
Note 1105 DBUG: [1] arg=2 handler=0 (time)
Note 1105 DBUG: [2] arg=3 handler=0 (time)
Note 1105 DBUG: [3] arg=4 handler=3 (datetime)
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
SELECT TIME'10:20:30' IN (102030, 102030, TIME'10:20:30',TIMESTAMP'2001-01-01 10:20:32',NULL);
TIME'10:20:30' IN (102030, 102030, TIME'10:20:30',TIMESTAMP'2001-01-01 10:20:32',NULL)
1
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (time)
Note 1105 DBUG: [1] arg=2 handler=0 (time)
Note 1105 DBUG: [2] arg=3 handler=0 (time)
Note 1105 DBUG: [3] arg=4 handler=3 (datetime)
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
SELECT TIME'10:20:30' NOT IN (1,TIME'10:20:30');
TIME'10:20:30' NOT IN (1,TIME'10:20:30')
0
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (time)
Note 1105 DBUG: [1] arg=2 handler=0 (time)
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
SELECT TIME'10:20:30' NOT IN (1,TIME'10:20:30',NULL);
TIME'10:20:30' NOT IN (1,TIME'10:20:30',NULL)
0
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (time)
Note 1105 DBUG: [1] arg=2 handler=0 (time)
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
SELECT TIME'10:20:30' NOT IN (102030, TIME'10:20:30',TIMESTAMP'2001-01-01 10:20:32');
TIME'10:20:30' NOT IN (102030, TIME'10:20:30',TIMESTAMP'2001-01-01 10:20:32')
0
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (time)
Note 1105 DBUG: [1] arg=2 handler=0 (time)
Note 1105 DBUG: [2] arg=3 handler=2 (datetime)
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
SELECT TIME'10:20:30' NOT IN (102030, TIME'10:20:30',TIMESTAMP'2001-01-01 10:20:32',NULL);
TIME'10:20:30' NOT IN (102030, TIME'10:20:30',TIMESTAMP'2001-01-01 10:20:32',NULL)
0
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (time)
Note 1105 DBUG: [1] arg=2 handler=0 (time)
Note 1105 DBUG: [2] arg=3 handler=2 (datetime)
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
SELECT TIME'10:20:30' NOT IN (102030, 102030, TIME'10:20:30',TIMESTAMP'2001-01-01 10:20:32');
TIME'10:20:30' NOT IN (102030, 102030, TIME'10:20:30',TIMESTAMP'2001-01-01 10:20:32')
0
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (time)
Note 1105 DBUG: [1] arg=2 handler=0 (time)
Note 1105 DBUG: [2] arg=3 handler=0 (time)
Note 1105 DBUG: [3] arg=4 handler=3 (datetime)
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
SELECT TIME'10:20:30' NOT IN (102030, 102030, TIME'10:20:30',TIMESTAMP'2001-01-01 10:20:32',NULL);
TIME'10:20:30' NOT IN (102030, 102030, TIME'10:20:30',TIMESTAMP'2001-01-01 10:20:32',NULL)
0
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (time)
Note 1105 DBUG: [1] arg=2 handler=0 (time)
Note 1105 DBUG: [2] arg=3 handler=0 (time)
Note 1105 DBUG: [3] arg=4 handler=3 (datetime)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
# Column predicant, incompatible types, no bisect
CREATE TABLE t1 (a INT);
SELECT a IN (1,1e0) FROM t1;
a IN (1,1e0)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT a IN (1,1e0,NULL) FROM t1;
a IN (1,1e0,NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a IN (CAST(1 AS SIGNED), CAST(1 AS UNSIGNED)) FROM t1;
a IN (CAST(1 AS SIGNED), CAST(1 AS UNSIGNED))
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=1 (decimal)
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a IN (CAST(1 AS SIGNED), CAST(1 AS UNSIGNED),NULL) FROM t1;
a IN (CAST(1 AS SIGNED), CAST(1 AS UNSIGNED),NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=1 (decimal)
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a IN (CAST(1 AS DECIMAL),CAST(1 AS SIGNED), CAST(1 AS UNSIGNED)) FROM t1;
a IN (CAST(1 AS DECIMAL),CAST(1 AS SIGNED), CAST(1 AS UNSIGNED))
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=1 (bigint)
Note 1105 DBUG: [2] arg=3 handler=0 (decimal)
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a IN (CAST(1 AS DECIMAL),CAST(1 AS SIGNED), CAST(1 AS UNSIGNED),NULL) FROM t1;
a IN (CAST(1 AS DECIMAL),CAST(1 AS SIGNED), CAST(1 AS UNSIGNED),NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=1 (bigint)
Note 1105 DBUG: [2] arg=3 handler=0 (decimal)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT a NOT IN (1,1e0) FROM t1;
a NOT IN (1,1e0)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT a NOT IN (1,1e0,NULL) FROM t1;
a NOT IN (1,1e0,NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a NOT IN (CAST(1 AS SIGNED), CAST(1 AS UNSIGNED)) FROM t1;
a NOT IN (CAST(1 AS SIGNED), CAST(1 AS UNSIGNED))
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=1 (decimal)
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a NOT IN (CAST(1 AS SIGNED), CAST(1 AS UNSIGNED),NULL) FROM t1;
a NOT IN (CAST(1 AS SIGNED), CAST(1 AS UNSIGNED),NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=1 (decimal)
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a NOT IN (CAST(1 AS DECIMAL),CAST(1 AS SIGNED), CAST(1 AS UNSIGNED)) FROM t1;
a NOT IN (CAST(1 AS DECIMAL),CAST(1 AS SIGNED), CAST(1 AS UNSIGNED))
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=1 (bigint)
Note 1105 DBUG: [2] arg=3 handler=0 (decimal)
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a NOT IN (CAST(1 AS DECIMAL),CAST(1 AS SIGNED), CAST(1 AS UNSIGNED),NULL) FROM t1;
a NOT IN (CAST(1 AS DECIMAL),CAST(1 AS SIGNED), CAST(1 AS UNSIGNED),NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=1 (bigint)
Note 1105 DBUG: [2] arg=3 handler=0 (decimal)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT a IN (1,1.0) FROM t1;
a IN (1,1.0)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=1 (decimal)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT a IN (1,1.0,NULL) FROM t1;
a IN (1,1.0,NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=1 (decimal)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT a NOT IN (1,1.0) FROM t1;
a NOT IN (1,1.0)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=1 (decimal)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT a NOT IN (1,1.0,NULL) FROM t1;
a NOT IN (1,1.0,NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=1 (decimal)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT a IN (1,'1') FROM t1;
a IN (1,'1')
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT a IN (1,'1',NULL) FROM t1;
a IN (1,'1',NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT a NOT IN (1,'1') FROM t1;
a NOT IN (1,'1')
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT a NOT IN (1,'1',NULL) FROM t1;
a NOT IN (1,'1',NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT a IN (1,TIME'10:20:30') FROM t1;
a IN (1,TIME'10:20:30')
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=1 (time)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT a IN (1,TIME'10:20:30',NULL) FROM t1;
a IN (1,TIME'10:20:30',NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=1 (time)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT a NOT IN (1,TIME'10:20:30') FROM t1;
a NOT IN (1,TIME'10:20:30')
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=1 (time)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT a NOT IN (1,TIME'10:20:30',NULL) FROM t1;
a NOT IN (1,TIME'10:20:30',NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=1 (time)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
DROP TABLE t1;
CREATE TABLE t1 (a DECIMAL(10,0));
SELECT a IN (1,1e0) FROM t1;
a IN (1,1e0)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT a IN (1,1e0,NULL) FROM t1;
a IN (1,1e0,NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT a NOT IN (1,1e0) FROM t1;
a NOT IN (1,1e0)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT a NOT IN (1,1e0,NULL) FROM t1;
a NOT IN (1,1e0,NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT a IN (1,'1') FROM t1;
a IN (1,'1')
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT a IN (1,'1',NULL) FROM t1;
a IN (1,'1',NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT a NOT IN (1,'1') FROM t1;
a NOT IN (1,'1')
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT a NOT IN (1,'1',NULL) FROM t1;
a NOT IN (1,'1',NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT a IN (1,TIME'10:20:30') FROM t1;
a IN (1,TIME'10:20:30')
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=1 (time)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT a IN (1,TIME'10:20:30',NULL) FROM t1;
a IN (1,TIME'10:20:30',NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=1 (time)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT a NOT IN (1,TIME'10:20:30') FROM t1;
a NOT IN (1,TIME'10:20:30')
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=1 (time)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT a NOT IN (1,TIME'10:20:30',NULL) FROM t1;
a NOT IN (1,TIME'10:20:30',NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=1 (time)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
DROP TABLE t1;
CREATE TABLE t1 (a DOUBLE);
SELECT a IN (1,TIME'10:20:30') FROM t1;
a IN (1,TIME'10:20:30')
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (double)
Note 1105 DBUG: [1] arg=2 handler=1 (time)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT a IN (1,TIME'10:20:30',NULL) FROM t1;
a IN (1,TIME'10:20:30',NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (double)
Note 1105 DBUG: [1] arg=2 handler=1 (time)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT a NOT IN (1,TIME'10:20:30') FROM t1;
a NOT IN (1,TIME'10:20:30')
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (double)
Note 1105 DBUG: [1] arg=2 handler=1 (time)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT a NOT IN (1,TIME'10:20:30',NULL) FROM t1;
a NOT IN (1,TIME'10:20:30',NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (double)
Note 1105 DBUG: [1] arg=2 handler=1 (time)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT a IN (1,DATE'2001-01-01') FROM t1;
a IN (1,DATE'2001-01-01')
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (double)
2017-05-06 00:04:15 +04:00
Note 1105 DBUG: [1] arg=2 handler=1 (date)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT a IN (1,DATE'2001-01-01',NULL) FROM t1;
a IN (1,DATE'2001-01-01',NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (double)
2017-05-06 00:04:15 +04:00
Note 1105 DBUG: [1] arg=2 handler=1 (date)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT a NOT IN (1,DATE'2001-01-01') FROM t1;
a NOT IN (1,DATE'2001-01-01')
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (double)
2017-05-06 00:04:15 +04:00
Note 1105 DBUG: [1] arg=2 handler=1 (date)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT a NOT IN (1,DATE'2001-01-01',NULL) FROM t1;
a NOT IN (1,DATE'2001-01-01',NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (double)
2017-05-06 00:04:15 +04:00
Note 1105 DBUG: [1] arg=2 handler=1 (date)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT a IN (1,TIMESTAMP'2001-01-01 10:20:30') FROM t1;
a IN (1,TIMESTAMP'2001-01-01 10:20:30')
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (double)
Note 1105 DBUG: [1] arg=2 handler=1 (datetime)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT a IN (1,TIMESTAMP'2001-01-01 10:20:30',NULL) FROM t1;
a IN (1,TIMESTAMP'2001-01-01 10:20:30',NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (double)
Note 1105 DBUG: [1] arg=2 handler=1 (datetime)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT a NOT IN (1,TIMESTAMP'2001-01-01 10:20:30') FROM t1;
a NOT IN (1,TIMESTAMP'2001-01-01 10:20:30')
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (double)
Note 1105 DBUG: [1] arg=2 handler=1 (datetime)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT a NOT IN (1,TIMESTAMP'2001-01-01 10:20:30',NULL) FROM t1;
a NOT IN (1,TIMESTAMP'2001-01-01 10:20:30',NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (double)
Note 1105 DBUG: [1] arg=2 handler=1 (datetime)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
DROP TABLE t1;
CREATE TABLE t1 (a VARCHAR(10));
SELECT a IN ('a',1) FROM t1;
a IN ('a',1)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (longblob)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT a IN ('a',TIME'10:20:30') FROM t1;
a IN ('a',TIME'10:20:30')
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (longblob)
Note 1105 DBUG: [1] arg=2 handler=1 (time)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT a NOT IN ('a',1) FROM t1;
a NOT IN ('a',1)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (longblob)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
SELECT a NOT IN ('a',TIME'10:20:30') FROM t1;
a NOT IN ('a',TIME'10:20:30')
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (longblob)
Note 1105 DBUG: [1] arg=2 handler=1 (time)
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
DROP TABLE t1;
CREATE TABLE t1 (a TIME);
SELECT a IN (102030, TIME'10:20:30',TIMESTAMP'2001-01-01 10:20:32') FROM t1;
a IN (102030, TIME'10:20:30',TIMESTAMP'2001-01-01 10:20:32')
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (time)
Note 1105 DBUG: [1] arg=2 handler=0 (time)
Note 1105 DBUG: [2] arg=3 handler=2 (datetime)
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a IN (102030, TIME'10:20:30',TIMESTAMP'2001-01-01 10:20:32',NULL) FROM t1;
a IN (102030, TIME'10:20:30',TIMESTAMP'2001-01-01 10:20:32',NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (time)
Note 1105 DBUG: [1] arg=2 handler=0 (time)
Note 1105 DBUG: [2] arg=3 handler=2 (datetime)
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a IN (102030, 102030, TIME'10:20:30',TIMESTAMP'2001-01-01 10:20:32') FROM t1;
a IN (102030, 102030, TIME'10:20:30',TIMESTAMP'2001-01-01 10:20:32')
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (time)
Note 1105 DBUG: [1] arg=2 handler=0 (time)
Note 1105 DBUG: [2] arg=3 handler=0 (time)
Note 1105 DBUG: [3] arg=4 handler=3 (datetime)
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a IN (102030, 102030, TIME'10:20:30',TIMESTAMP'2001-01-01 10:20:32',NULL) FROM t1;
a IN (102030, 102030, TIME'10:20:30',TIMESTAMP'2001-01-01 10:20:32',NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (time)
Note 1105 DBUG: [1] arg=2 handler=0 (time)
Note 1105 DBUG: [2] arg=3 handler=0 (time)
Note 1105 DBUG: [3] arg=4 handler=3 (datetime)
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a NOT IN (102030, TIME'10:20:30',TIMESTAMP'2001-01-01 10:20:32') FROM t1;
a NOT IN (102030, TIME'10:20:30',TIMESTAMP'2001-01-01 10:20:32')
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (time)
Note 1105 DBUG: [1] arg=2 handler=0 (time)
Note 1105 DBUG: [2] arg=3 handler=2 (datetime)
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a NOT IN (102030, TIME'10:20:30',TIMESTAMP'2001-01-01 10:20:32',NULL) FROM t1;
a NOT IN (102030, TIME'10:20:30',TIMESTAMP'2001-01-01 10:20:32',NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (time)
Note 1105 DBUG: [1] arg=2 handler=0 (time)
Note 1105 DBUG: [2] arg=3 handler=2 (datetime)
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a NOT IN (102030, 102030, TIME'10:20:30',TIMESTAMP'2001-01-01 10:20:32') FROM t1;
a NOT IN (102030, 102030, TIME'10:20:30',TIMESTAMP'2001-01-01 10:20:32')
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (time)
Note 1105 DBUG: [1] arg=2 handler=0 (time)
Note 1105 DBUG: [2] arg=3 handler=0 (time)
Note 1105 DBUG: [3] arg=4 handler=3 (datetime)
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a NOT IN (102030, 102030, TIME'10:20:30',TIMESTAMP'2001-01-01 10:20:32',NULL) FROM t1;
a NOT IN (102030, 102030, TIME'10:20:30',TIMESTAMP'2001-01-01 10:20:32',NULL)
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (time)
Note 1105 DBUG: [1] arg=2 handler=0 (time)
Note 1105 DBUG: [2] arg=3 handler=0 (time)
Note 1105 DBUG: [3] arg=4 handler=3 (datetime)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
2016-12-10 22:25:17 +04:00
DROP TABLE t1;
# Not top level, negated: cond3 is false
CREATE TABLE t1 (a INT);
SELECT ROW(a,a) NOT IN ((1,1),(2,NULL)) FROM t1;
ROW(a,a) NOT IN ((1,1),(2,NULL))
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=no
2016-12-10 22:25:17 +04:00
SELECT ROW(a,a) NOT IN ((1,1),(2,2)) FROM t1;
ROW(a,a) NOT IN ((1,1),(2,2))
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=no
2016-12-10 22:25:17 +04:00
DROP TABLE t1;
CREATE TABLE t1 (a INT NOT NULL, b INT);
SELECT ROW(a,a) NOT IN ((1,1),(2,NULL)) FROM t1;
ROW(a,a) NOT IN ((1,1),(2,NULL))
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=no
2016-12-10 22:25:17 +04:00
SELECT ROW(a,a) NOT IN ((1,1),(2,2)) FROM t1;
ROW(a,a) NOT IN ((1,1),(2,2))
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
DROP TABLE t1;
CREATE TABLE t1 (a INT);
SELECT ROW(a,(a,a)) NOT IN ((1,(1,1)),(2,(2,NULL))) FROM t1;
ROW(a,(a,a)) NOT IN ((1,(1,1)),(2,(2,NULL)))
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=no
2016-12-10 22:25:17 +04:00
SELECT ROW(a,(a,a)) NOT IN ((1,(1,1)),(2,(2,2))) FROM t1;
ROW(a,(a,a)) NOT IN ((1,(1,1)),(2,(2,2)))
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=no
2016-12-10 22:25:17 +04:00
DROP TABLE t1;
CREATE TABLE t1 (a INT NOT NULL);
SELECT ROW(a,(a,a)) NOT IN ((1,(1,1)),(2,(2,NULL))) FROM t1;
ROW(a,(a,a)) NOT IN ((1,(1,1)),(2,(2,NULL)))
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=no
2016-12-10 22:25:17 +04:00
SELECT ROW(a,(a,a)) NOT IN ((1,(1,1)),(2,(2,2))) FROM t1;
ROW(a,(a,a)) NOT IN ((1,(1,1)),(2,(2,2)))
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
DROP TABLE t1;
# Not top level, not negated: cond3 is false
CREATE TABLE t1 (a INT);
SELECT ROW(a,a) IN ((1,1),(2,NULL)) FROM t1;
ROW(a,a) IN ((1,1),(2,NULL))
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=no
2016-12-10 22:25:17 +04:00
SELECT ROW(a,a) IN ((1,1),(2,2)) FROM t1;
ROW(a,a) IN ((1,1),(2,2))
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=no
2016-12-10 22:25:17 +04:00
DROP TABLE t1;
CREATE TABLE t1 (a INT NOT NULL);
SELECT ROW(a,a) IN ((1,1),(2,NULL)) FROM t1;
ROW(a,a) IN ((1,1),(2,NULL))
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=no
2016-12-10 22:25:17 +04:00
SELECT ROW(a,a) IN ((1,1),(2,2)) FROM t1;
ROW(a,a) IN ((1,1),(2,2))
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
DROP TABLE t1;
CREATE TABLE t1 (a INT);
SELECT ROW(a,(a,a)) IN ((1,(1,1)),(2,(2,NULL))) FROM t1;
ROW(a,(a,a)) IN ((1,(1,1)),(2,(2,NULL)))
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=no
2016-12-10 22:25:17 +04:00
SELECT ROW(a,(a,a)) IN ((1,(1,1)),(2,(2,2))) FROM t1;
ROW(a,(a,a)) IN ((1,(1,1)),(2,(2,2)))
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=no
2016-12-10 22:25:17 +04:00
DROP TABLE t1;
CREATE TABLE t1 (a INT NOT NULL);
SELECT ROW(a,(a,a)) IN ((1,(1,1)),(2,(2,NULL))) FROM t1;
ROW(a,(a,a)) IN ((1,(1,1)),(2,(2,NULL)))
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=no
2016-12-10 22:25:17 +04:00
SELECT ROW(a,(a,a)) IN ((1,(1,1)),(2,(2,2))) FROM t1;
ROW(a,(a,a)) IN ((1,(1,1)),(2,(2,2)))
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
DROP TABLE t1;
# Top level, negated: cond3 is false
CREATE TABLE t1 (a INT);
SELECT 1 FROM t1 WHERE ROW(a,a) NOT IN ((1,1),(2,NULL));
1
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=no
2016-12-10 22:25:17 +04:00
SELECT 1 FROM t1 WHERE ROW(a,a) NOT IN ((1,1),(2,2));
1
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=no
2016-12-10 22:25:17 +04:00
DROP TABLE t1;
CREATE TABLE t1 (a INT NOT NULL);
SELECT 1 FROM t1 WHERE ROW(a,a) NOT IN ((1,1),(2,NULL));
1
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=no
2016-12-10 22:25:17 +04:00
SELECT 1 FROM t1 WHERE ROW(a,a) NOT IN ((1,1),(2,2));
1
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
DROP TABLE t1;
CREATE TABLE t1 (a INT);
SELECT 1 FROM t1 WHERE ROW(a,(a,a)) NOT IN ((1,(1,1)),(2,(2,NULL)));
1
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=no
2016-12-10 22:25:17 +04:00
SELECT 1 FROM t1 WHERE ROW(a,(a,a)) NOT IN ((1,(1,1)),(2,(2,2)));
1
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=no
2016-12-10 22:25:17 +04:00
DROP TABLE t1;
CREATE TABLE t1 (a INT NOT NULL);
SELECT 1 FROM t1 WHERE ROW(a,(a,a)) NOT IN ((1,(1,1)),(2,(2,NULL)));
1
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=no
2016-12-10 22:25:17 +04:00
SELECT 1 FROM t1 WHERE ROW(a,(a,a)) NOT IN ((1,(1,1)),(2,(2,2)));
1
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
DROP TABLE t1;
# Top level, not negated: cond3 is true
CREATE TABLE t1 (a INT);
SELECT 1 FROM t1 WHERE ROW(a,a) IN ((1,1),(2,NULL));
1
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT 1 FROM t1 WHERE ROW(a,a) IN ((1,1),(2,2));
1
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
DROP TABLE t1;
CREATE TABLE t1 (a INT NOT NULL);
SELECT 1 FROM t1 WHERE ROW(a,a) IN ((1,1),(2,NULL));
1
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT 1 FROM t1 WHERE ROW(a,a) IN ((1,1),(2,2));
1
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
DROP TABLE t1;
CREATE TABLE t1 (a INT);
SELECT 1 FROM t1 WHERE ROW(a,(a,a)) IN ((1,(1,1)),(2,(2,NULL)));
1
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT 1 FROM t1 WHERE ROW(a,(a,a)) IN ((1,(1,1)),(2,(2,2)));
1
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
DROP TABLE t1;
CREATE TABLE t1 (a INT NOT NULL);
SELECT 1 FROM t1 WHERE ROW(a,(a,a)) IN ((1,(1,1)),(2,(2,NULL)));
1
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
2016-12-10 22:25:17 +04:00
SELECT 1 FROM t1 WHERE ROW(a,(a,a)) IN ((1,(1,1)),(2,(2,2)));
1
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
DROP TABLE t1;
#
# MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
#
SELECT TIME'10:20:30' IN (102030,TIME'10:20:31',TIMESTAMP'2001-01-01 10:20:32');
TIME'10:20:30' IN (102030,TIME'10:20:31',TIMESTAMP'2001-01-01 10:20:32')
1
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (time)
Note 1105 DBUG: [1] arg=2 handler=0 (time)
Note 1105 DBUG: [2] arg=3 handler=2 (datetime)
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
PREPARE stmt FROM "SELECT
TIME'10:20:30' IN (102030,TIME'10:20:31',TIMESTAMP'2001-01-01 10:20:32')";
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (time)
Note 1105 DBUG: [1] arg=2 handler=0 (time)
Note 1105 DBUG: [2] arg=3 handler=2 (datetime)
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
EXECUTE stmt;
TIME'10:20:30' IN (102030,TIME'10:20:31',TIMESTAMP'2001-01-01 10:20:32')
1
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (time)
Note 1105 DBUG: [1] arg=2 handler=0 (time)
Note 1105 DBUG: [2] arg=3 handler=2 (datetime)
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
EXECUTE stmt;
TIME'10:20:30' IN (102030,TIME'10:20:31',TIMESTAMP'2001-01-01 10:20:32')
1
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (time)
Note 1105 DBUG: [1] arg=2 handler=0 (time)
Note 1105 DBUG: [2] arg=3 handler=2 (datetime)
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
DEALLOCATE PREPARE stmt;
CREATE TABLE t1 (a VARCHAR(10));
INSERT INTO t1 VALUES ('A'),('B'),('A');
SELECT a,NULL AS b FROM t1 GROUP BY a HAVING 'A' IN (b,'A');
a b
A NULL
B NULL
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=2 handler=0 (longblob)
2016-12-17 22:53:48 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
SELECT a,NULL AS b FROM t1 GROUP BY a HAVING 'A' IN ('A',b);
a b
A NULL
B NULL
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (longblob)
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
Note 1105 DBUG: types_compatible=yes bisect=yes
SELECT a,NULL AS b FROM t1 GROUP BY a HAVING 'A' IN (b,a);
a b
A NULL
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=2 handler=0 (longblob)
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
Note 1105 DBUG: types_compatible=yes bisect=no
SELECT a,NULL AS b FROM t1 GROUP BY a HAVING 'A' IN (a,b);
a b
A NULL
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (longblob)
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
Note 1105 DBUG: types_compatible=yes bisect=no
SELECT a,NULL AS b FROM t1 GROUP BY a HAVING 'A' IN (b,'A',10);
a b
A NULL
B NULL
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=2 handler=0 (longblob)
Note 1105 DBUG: [1] arg=3 handler=1 (double)
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a,NULL AS b FROM t1 GROUP BY a HAVING 'A' IN ('A',b,10);
a b
A NULL
B NULL
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (longblob)
Note 1105 DBUG: [1] arg=3 handler=1 (double)
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a,NULL AS b FROM t1 GROUP BY a HAVING 'A' IN (b,a,10);
a b
A NULL
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=2 handler=0 (longblob)
Note 1105 DBUG: [1] arg=3 handler=1 (double)
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
Warning 1292 Truncated incorrect DOUBLE value: 'A'
SELECT a,NULL AS b FROM t1 GROUP BY a HAVING 'A' IN (a,b,10);
a b
A NULL
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (longblob)
Note 1105 DBUG: [1] arg=3 handler=1 (double)
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
Warning 1292 Truncated incorrect DOUBLE value: 'A'
DROP TABLE t1;
#
# MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
#
CREATE TABLE t1 (a BIGINT, b BIGINT UNSIGNED);
INSERT INTO t1 VALUES (-9223372036854775808,18446744073709551615);
SELECT * FROM t1 WHERE -1 IN (a,b);
a b
Warnings:
2016-12-29 12:38:45 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=1 (decimal)
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
Note 1105 DBUG: types_compatible=no bisect=no
DROP TABLE t1;
#
# MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
#
CREATE TABLE t1 (a BIGINT, b BIGINT UNSIGNED);
INSERT INTO t1 VALUES (-9223372036854775808,18446744073709551615);
SELECT
CASE -1
WHEN -9223372036854775808 THEN 'one'
WHEN 18446744073709551615 THEN 'two'
END AS c;
c
NULL
Warnings:
2017-09-22 12:45:34 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
cleanup: Item_func_case
reorder items in args[] array. Instead of
when1,then1,when2,then2,...[,case][,else]
sort them as
[case,]when1,when2,...,then1,then2,...[,else]
in this case all items used for comparison take a continuous part
of the array and can be aggregated directly. and all items that
can be returned take a continuous part of the array and can be
aggregated directly. Old code had to copy them to a temporary
array before aggreation, and then copy back (thd->change_item_tree)
everything that was changed.
this is a 10.3 version of bf1ca14ff3f
2018-03-28 20:16:13 +02:00
Note 1105 DBUG: [1] arg=2 handler=1 (decimal)
2016-12-10 22:25:17 +04:00
DROP TABLE t1;
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
#
# MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
#
SELECT
CASE TIME'10:20:30'
WHEN 102030 THEN 'one'
WHEN TIME'10:20:31' THEN 'two'
END AS good,
CASE TIME'10:20:30'
WHEN 102030 THEN 'one'
WHEN TIME'10:20:31' THEN 'two'
WHEN TIMESTAMP'2001-01-01 10:20:32' THEN 'three'
END AS was_bad_now_good;
good was_bad_now_good
one one
Warnings:
2017-09-22 12:45:34 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (time)
cleanup: Item_func_case
reorder items in args[] array. Instead of
when1,then1,when2,then2,...[,case][,else]
sort them as
[case,]when1,when2,...,then1,then2,...[,else]
in this case all items used for comparison take a continuous part
of the array and can be aggregated directly. and all items that
can be returned take a continuous part of the array and can be
aggregated directly. Old code had to copy them to a temporary
array before aggreation, and then copy back (thd->change_item_tree)
everything that was changed.
this is a 10.3 version of bf1ca14ff3f
2018-03-28 20:16:13 +02:00
Note 1105 DBUG: [1] arg=2 handler=0 (time)
2017-09-22 12:45:34 +04:00
Note 1105 DBUG: [0] arg=1 handler=0 (time)
cleanup: Item_func_case
reorder items in args[] array. Instead of
when1,then1,when2,then2,...[,case][,else]
sort them as
[case,]when1,when2,...,then1,then2,...[,else]
in this case all items used for comparison take a continuous part
of the array and can be aggregated directly. and all items that
can be returned take a continuous part of the array and can be
aggregated directly. Old code had to copy them to a temporary
array before aggreation, and then copy back (thd->change_item_tree)
everything that was changed.
this is a 10.3 version of bf1ca14ff3f
2018-03-28 20:16:13 +02:00
Note 1105 DBUG: [1] arg=2 handler=0 (time)
Note 1105 DBUG: [2] arg=3 handler=2 (datetime)
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
SET SESSION debug_dbug="-d,Predicant_to_list_comparator";
2016-12-10 22:25:17 +04:00
SET SESSION debug_dbug="-d,Item_func_in";