mariadb/mysql-test/main/func_debug.result

1658 lines
60 KiB
Text
Raw Normal View History

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";
# Constant predicant, compatible types, bisect
SELECT 1 IN (1,2);
1 IN (1,2)
1
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=0 (bigint)
Note 1105 DBUG: types_compatible=yes bisect=yes
SELECT 1 IN (1,2,NULL);
1 IN (1,2,NULL)
1
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=0 (bigint)
Note 1105 DBUG: types_compatible=yes bisect=yes
SELECT 1 NOT IN (1,2);
1 NOT IN (1,2)
0
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=0 (bigint)
Note 1105 DBUG: types_compatible=yes bisect=yes
SELECT 1 NOT IN (1,2,NULL);
1 NOT IN (1,2,NULL)
0
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=0 (bigint)
Note 1105 DBUG: types_compatible=yes bisect=yes
SELECT 1.0 IN (1.0,2.0);
1.0 IN (1.0,2.0)
1
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=0 (decimal)
Note 1105 DBUG: types_compatible=yes bisect=yes
SELECT 1.0 IN (1.0,2.0,NULL);
1.0 IN (1.0,2.0,NULL)
1
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=0 (decimal)
Note 1105 DBUG: types_compatible=yes bisect=yes
SELECT 1.0 NOT IN (1.0,2.0);
1.0 NOT IN (1.0,2.0)
0
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=0 (decimal)
Note 1105 DBUG: types_compatible=yes bisect=yes
SELECT 1.0 NOT IN (1.0,2.0,NULL);
1.0 NOT IN (1.0,2.0,NULL)
0
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=0 (decimal)
Note 1105 DBUG: types_compatible=yes bisect=yes
SELECT 1e0 IN (1e0,2e0);
1e0 IN (1e0,2e0)
1
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (double)
Note 1105 DBUG: [1] arg=2 handler=0 (double)
Note 1105 DBUG: types_compatible=yes bisect=yes
SELECT 1e0 IN (1e0,2e0,NULL);
1e0 IN (1e0,2e0,NULL)
1
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (double)
Note 1105 DBUG: [1] arg=2 handler=0 (double)
Note 1105 DBUG: types_compatible=yes bisect=yes
SELECT 1e0 NOT IN (1e0,2e0);
1e0 NOT IN (1e0,2e0)
0
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (double)
Note 1105 DBUG: [1] arg=2 handler=0 (double)
Note 1105 DBUG: types_compatible=yes bisect=yes
SELECT 1e0 NOT IN (1e0,2e0,NULL);
1e0 NOT IN (1e0,2e0,NULL)
0
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (double)
Note 1105 DBUG: [1] arg=2 handler=0 (double)
Note 1105 DBUG: types_compatible=yes bisect=yes
SELECT 'a' IN ('a','b');
'a' IN ('a','b')
1
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (longblob)
Note 1105 DBUG: [1] arg=2 handler=0 (longblob)
Note 1105 DBUG: types_compatible=yes bisect=yes
SELECT 'a' IN ('a','b',NULL);
'a' IN ('a','b',NULL)
1
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (longblob)
Note 1105 DBUG: [1] arg=2 handler=0 (longblob)
Note 1105 DBUG: types_compatible=yes bisect=yes
SELECT 'a' NOT IN ('a','b');
'a' NOT IN ('a','b')
0
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (longblob)
Note 1105 DBUG: [1] arg=2 handler=0 (longblob)
Note 1105 DBUG: types_compatible=yes bisect=yes
SELECT 'a' NOT IN ('a','b',NULL);
'a' NOT IN ('a','b',NULL)
0
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (longblob)
Note 1105 DBUG: [1] arg=2 handler=0 (longblob)
Note 1105 DBUG: types_compatible=yes bisect=yes
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:
Note 1105 DBUG: [0] arg=1 handler=0 (datetime)
Note 1105 DBUG: [1] arg=2 handler=0 (datetime)
Note 1105 DBUG: types_compatible=yes bisect=yes
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:
Note 1105 DBUG: [0] arg=1 handler=0 (datetime)
Note 1105 DBUG: [1] arg=2 handler=0 (datetime)
Note 1105 DBUG: types_compatible=yes bisect=yes
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:
Note 1105 DBUG: [0] arg=1 handler=0 (datetime)
Note 1105 DBUG: [1] arg=2 handler=0 (datetime)
Note 1105 DBUG: types_compatible=yes bisect=yes
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:
Note 1105 DBUG: [0] arg=1 handler=0 (datetime)
Note 1105 DBUG: [1] arg=2 handler=0 (datetime)
Note 1105 DBUG: types_compatible=yes bisect=yes
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:
Note 1105 DBUG: [0] arg=1 handler=0 (time)
Note 1105 DBUG: [1] arg=2 handler=0 (time)
Note 1105 DBUG: types_compatible=yes bisect=yes
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:
Note 1105 DBUG: [0] arg=1 handler=0 (time)
Note 1105 DBUG: [1] arg=2 handler=0 (time)
Note 1105 DBUG: types_compatible=yes bisect=yes
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:
Note 1105 DBUG: [0] arg=1 handler=0 (time)
Note 1105 DBUG: [1] arg=2 handler=0 (time)
Note 1105 DBUG: types_compatible=yes bisect=yes
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:
Note 1105 DBUG: [0] arg=1 handler=0 (time)
Note 1105 DBUG: [1] arg=2 handler=0 (time)
Note 1105 DBUG: types_compatible=yes bisect=yes
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:
Note 1105 DBUG: [0] arg=1 handler=0 (date)
Note 1105 DBUG: [1] arg=2 handler=0 (date)
Note 1105 DBUG: types_compatible=yes bisect=yes
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:
Note 1105 DBUG: [0] arg=1 handler=0 (date)
Note 1105 DBUG: [1] arg=2 handler=0 (date)
Note 1105 DBUG: types_compatible=yes bisect=yes
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:
Note 1105 DBUG: [0] arg=1 handler=0 (date)
Note 1105 DBUG: [1] arg=2 handler=0 (date)
Note 1105 DBUG: types_compatible=yes bisect=yes
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:
Note 1105 DBUG: [0] arg=1 handler=0 (date)
Note 1105 DBUG: [1] arg=2 handler=0 (date)
Note 1105 DBUG: types_compatible=yes bisect=yes
# 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:
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;
CREATE TABLE t1 (a INT);
SELECT a IN (1,2,3) FROM t1;
a IN (1,2,3)
Warnings:
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: types_compatible=yes bisect=yes
SELECT a IN (1,2,3,NULL) FROM t1;
a IN (1,2,3,NULL)
Warnings:
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:
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:
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=0 (decimal)
Note 1105 DBUG: types_compatible=yes bisect=yes
SELECT a NOT IN (1,2,3) FROM t1;
a NOT IN (1,2,3)
Warnings:
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: types_compatible=yes bisect=yes
SELECT a NOT IN (1,2,3,NULL) FROM t1;
a NOT IN (1,2,3,NULL)
Warnings:
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:
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:
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=0 (decimal)
Note 1105 DBUG: types_compatible=yes bisect=yes
DROP TABLE t1;
CREATE TABLE t1 (a DOUBLE);
SELECT a IN (1e0,2,3.0) FROM t1;
a IN (1e0,2,3.0)
Warnings:
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: types_compatible=yes bisect=yes
SELECT a IN (1e0,2,3.0,NULL) FROM t1;
a IN (1e0,2,3.0,NULL)
Warnings:
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: types_compatible=yes bisect=yes
SELECT a NOT IN (1e0,2,3.0) FROM t1;
a NOT IN (1e0,2,3.0)
Warnings:
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: types_compatible=yes bisect=yes
SELECT a NOT IN (1e0,2,3.0,NULL) FROM t1;
a NOT IN (1e0,2,3.0,NULL)
Warnings:
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: types_compatible=yes bisect=yes
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:
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: types_compatible=yes bisect=yes
SELECT a IN (1,2.0,3.0,NULL) FROM t1;
a IN (1,2.0,3.0,NULL)
Warnings:
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: types_compatible=yes bisect=yes
SELECT a NOT IN (1,2.0,3.0) FROM t1;
a NOT IN (1,2.0,3.0)
Warnings:
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: types_compatible=yes bisect=yes
SELECT a NOT IN (1,2.0,3.0,NULL) FROM t1;
a NOT IN (1,2.0,3.0,NULL)
Warnings:
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: types_compatible=yes bisect=yes
DROP TABLE t1;
CREATE TABLE t1 (a VARCHAR(10));
SELECT a IN ('a','b','c') FROM t1;
a IN ('a','b','c')
Warnings:
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)
Note 1105 DBUG: types_compatible=yes bisect=yes
SELECT a IN ('a','b','c',NULL) FROM t1;
a IN ('a','b','c',NULL)
Warnings:
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)
Note 1105 DBUG: types_compatible=yes bisect=yes
SELECT a NOT IN ('a','b','c') FROM t1;
a NOT IN ('a','b','c')
Warnings:
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)
Note 1105 DBUG: types_compatible=yes bisect=yes
SELECT a NOT IN ('a','b','c',NULL) FROM t1;
a NOT IN ('a','b','c',NULL)
Warnings:
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)
Note 1105 DBUG: types_compatible=yes bisect=yes
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:
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)
Note 1105 DBUG: types_compatible=yes bisect=yes
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:
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)
Note 1105 DBUG: types_compatible=yes bisect=yes
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:
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)
Note 1105 DBUG: types_compatible=yes bisect=yes
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:
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)
Note 1105 DBUG: types_compatible=yes bisect=yes
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:
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)
Note 1105 DBUG: types_compatible=yes bisect=yes
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:
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)
Note 1105 DBUG: types_compatible=yes bisect=yes
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:
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)
Note 1105 DBUG: types_compatible=yes bisect=yes
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:
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)
Note 1105 DBUG: types_compatible=yes bisect=yes
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:
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)
Note 1105 DBUG: types_compatible=yes bisect=yes
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:
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)
Note 1105 DBUG: types_compatible=yes bisect=yes
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:
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)
Note 1105 DBUG: types_compatible=yes bisect=yes
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:
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)
Note 1105 DBUG: types_compatible=yes bisect=yes
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:
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)
Note 1105 DBUG: types_compatible=yes bisect=no
SELECT 1 IN (a,1,2,3,NULL) FROM t1;
1 IN (a,1,2,3,NULL)
Warnings:
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)
Note 1105 DBUG: types_compatible=yes bisect=no
SELECT 1 NOT IN (a,1,2,3) FROM t1;
1 NOT IN (a,1,2,3)
Warnings:
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)
Note 1105 DBUG: types_compatible=yes bisect=no
SELECT 1 NOT IN (a,1,2,3,NULL) FROM t1;
1 NOT IN (a,1,2,3,NULL)
Warnings:
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)
Note 1105 DBUG: types_compatible=yes bisect=no
DROP TABLE t1;
CREATE TABLE t1 (a DOUBLE);
SELECT 1 IN (a,1e0,2e0,3e0) FROM t1;
1 IN (a,1e0,2e0,3e0)
Warnings:
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)
Note 1105 DBUG: types_compatible=yes bisect=no
SELECT 1 IN (a,1e0,2e0,3e0,NULL) FROM t1;
1 IN (a,1e0,2e0,3e0,NULL)
Warnings:
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)
Note 1105 DBUG: types_compatible=yes bisect=no
SELECT 1 NOT IN (a,1e0,2e0,3e0) FROM t1;
1 NOT IN (a,1e0,2e0,3e0)
Warnings:
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)
Note 1105 DBUG: types_compatible=yes bisect=no
SELECT 1 NOT IN (a,1e0,2e0,3e0,NULL) FROM t1;
1 NOT IN (a,1e0,2e0,3e0,NULL)
Warnings:
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)
Note 1105 DBUG: types_compatible=yes bisect=no
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:
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)
Note 1105 DBUG: types_compatible=yes bisect=no
SELECT 1 IN (a,1.0,2.0,3.0,NULL) FROM t1;
1 IN (a,1.0,2.0,3.0,NULL)
Warnings:
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)
Note 1105 DBUG: types_compatible=yes bisect=no
SELECT 1 NOT IN (a,1.0,2.0,3.0) FROM t1;
1 NOT IN (a,1.0,2.0,3.0)
Warnings:
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)
Note 1105 DBUG: types_compatible=yes bisect=no
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:
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)
Note 1105 DBUG: types_compatible=yes bisect=no
DROP TABLE t1;
CREATE TABLE t1 (a VARCHAR(10));
SELECT 'a' IN (a,'b','c') FROM t1;
'a' IN (a,'b','c')
Warnings:
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)
Note 1105 DBUG: types_compatible=yes bisect=no
SELECT 'a' IN (a,'b','c',NULL) FROM t1;
'a' IN (a,'b','c',NULL)
Warnings:
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)
Note 1105 DBUG: types_compatible=yes bisect=no
SELECT 'a' NOT IN (a,'b','c') FROM t1;
'a' NOT IN (a,'b','c')
Warnings:
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)
Note 1105 DBUG: types_compatible=yes bisect=no
SELECT 'a' NOT IN (a,'b','c',NULL) FROM t1;
'a' NOT IN (a,'b','c',NULL)
Warnings:
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)
Note 1105 DBUG: types_compatible=yes bisect=no
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:
Note 1105 DBUG: [0] arg=1 handler=0 (date)
Note 1105 DBUG: [1] arg=2 handler=0 (date)
Note 1105 DBUG: types_compatible=yes bisect=no
SELECT DATE'2001-01-01' IN (a,'2001-01-01',NULL) FROM t1;
DATE'2001-01-01' IN (a,'2001-01-01',NULL)
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (date)
Note 1105 DBUG: [1] arg=2 handler=0 (date)
Note 1105 DBUG: types_compatible=yes bisect=no
SELECT DATE'2001-01-01' NOT IN (a,'2001-01-01') FROM t1;
DATE'2001-01-01' NOT IN (a,'2001-01-01')
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (date)
Note 1105 DBUG: [1] arg=2 handler=0 (date)
Note 1105 DBUG: types_compatible=yes bisect=no
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:
Note 1105 DBUG: [0] arg=1 handler=0 (date)
Note 1105 DBUG: [1] arg=2 handler=0 (date)
Note 1105 DBUG: types_compatible=yes bisect=no
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:
Note 1105 DBUG: [0] arg=1 handler=0 (time)
Note 1105 DBUG: [1] arg=2 handler=0 (time)
Note 1105 DBUG: types_compatible=yes bisect=no
SELECT TIME'10:20:30' IN (a,'10:20:30',NULL) FROM t1;
TIME'10:20:30' IN (a,'10:20:30',NULL)
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (time)
Note 1105 DBUG: [1] arg=2 handler=0 (time)
Note 1105 DBUG: types_compatible=yes bisect=no
SELECT TIME'10:20:30' NOT IN (a,'10:20:30') FROM t1;
TIME'10:20:30' NOT IN (a,'10:20:30')
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (time)
Note 1105 DBUG: [1] arg=2 handler=0 (time)
Note 1105 DBUG: types_compatible=yes bisect=no
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:
Note 1105 DBUG: [0] arg=1 handler=0 (time)
Note 1105 DBUG: [1] arg=2 handler=0 (time)
Note 1105 DBUG: types_compatible=yes bisect=no
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:
Note 1105 DBUG: [0] arg=1 handler=0 (datetime)
Note 1105 DBUG: [1] arg=2 handler=0 (datetime)
Note 1105 DBUG: types_compatible=yes bisect=no
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:
Note 1105 DBUG: [0] arg=1 handler=0 (datetime)
Note 1105 DBUG: [1] arg=2 handler=0 (datetime)
Note 1105 DBUG: types_compatible=yes bisect=no
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:
Note 1105 DBUG: [0] arg=1 handler=0 (datetime)
Note 1105 DBUG: [1] arg=2 handler=0 (datetime)
Note 1105 DBUG: types_compatible=yes bisect=no
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:
Note 1105 DBUG: [0] arg=1 handler=0 (datetime)
Note 1105 DBUG: [1] arg=2 handler=0 (datetime)
Note 1105 DBUG: types_compatible=yes bisect=no
DROP TABLE t1;
# Constant predicant, incompatible types, no bisect
SELECT 1 IN (1,2e0);
1 IN (1,2e0)
1
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT 1 IN (1,2e0,NULL);
1 IN (1,2e0,NULL)
1
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT 1 NOT IN (1,2e0);
1 NOT IN (1,2e0)
0
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT 1 NOT IN (1,2e0,NULL);
1 NOT IN (1,2e0,NULL)
0
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT 1.0 IN (1.0,2e0);
1.0 IN (1.0,2e0)
1
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT 1.0 IN (1.0,2e0,NULL);
1.0 IN (1.0,2e0,NULL)
1
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT 1.0 NOT IN (1.0,2e0);
1.0 NOT IN (1.0,2e0)
0
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT 1.0 NOT IN (1.0,2e0,NULL);
1.0 NOT IN (1.0,2e0,NULL)
0
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT 1e0 IN (1.0,TIME'10:20:30');
1e0 IN (1.0,TIME'10:20:30')
1
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (double)
Note 1105 DBUG: [1] arg=2 handler=1 (time)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT 1e0 IN (1.0,TIME'10:20:30',NULL);
1e0 IN (1.0,TIME'10:20:30',NULL)
1
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (double)
Note 1105 DBUG: [1] arg=2 handler=1 (time)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT 1e0 NOT IN (1.0,TIME'10:20:30');
1e0 NOT IN (1.0,TIME'10:20:30')
0
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (double)
Note 1105 DBUG: [1] arg=2 handler=1 (time)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT 1e0 NOT IN (1.0,TIME'10:20:30',NULL);
1e0 NOT IN (1.0,TIME'10:20:30',NULL)
0
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (double)
Note 1105 DBUG: [1] arg=2 handler=1 (time)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT 'a' IN ('a',2);
'a' IN ('a',2)
1
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (longblob)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT 'a' IN ('a',2,NULL);
'a' IN ('a',2,NULL)
1
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (longblob)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT 'a' NOT IN ('a',2);
'a' NOT IN ('a',2)
0
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (longblob)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT 'a' NOT IN ('a',2,NULL);
'a' NOT IN ('a',2,NULL)
0
Warnings:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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)
Note 1105 DBUG: types_compatible=no bisect=no
# Column predicant, incompatible types, no bisect
CREATE TABLE t1 (a INT);
SELECT a IN (1,1e0) FROM t1;
a IN (1,1e0)
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a IN (1,1e0,NULL) FROM t1;
a IN (1,1e0,NULL)
Warnings:
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:
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:
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:
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:
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)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a NOT IN (1,1e0) FROM t1;
a NOT IN (1,1e0)
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a NOT IN (1,1e0,NULL) FROM t1;
a NOT IN (1,1e0,NULL)
Warnings:
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:
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:
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:
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:
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)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a IN (1,1.0) FROM t1;
a IN (1,1.0)
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=1 (decimal)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a IN (1,1.0,NULL) FROM t1;
a IN (1,1.0,NULL)
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=1 (decimal)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a NOT IN (1,1.0) FROM t1;
a NOT IN (1,1.0)
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=1 (decimal)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a NOT IN (1,1.0,NULL) FROM t1;
a NOT IN (1,1.0,NULL)
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=1 (decimal)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a IN (1,'1') FROM t1;
a IN (1,'1')
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a IN (1,'1',NULL) FROM t1;
a IN (1,'1',NULL)
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a NOT IN (1,'1') FROM t1;
a NOT IN (1,'1')
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a NOT IN (1,'1',NULL) FROM t1;
a NOT IN (1,'1',NULL)
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a IN (1,TIME'10:20:30') FROM t1;
a IN (1,TIME'10:20:30')
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=1 (time)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a IN (1,TIME'10:20:30',NULL) FROM t1;
a IN (1,TIME'10:20:30',NULL)
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=1 (time)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a NOT IN (1,TIME'10:20:30') FROM t1;
a NOT IN (1,TIME'10:20:30')
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=1 (time)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a NOT IN (1,TIME'10:20:30',NULL) FROM t1;
a NOT IN (1,TIME'10:20:30',NULL)
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=1 (time)
Note 1105 DBUG: types_compatible=no bisect=no
DROP TABLE t1;
CREATE TABLE t1 (a DECIMAL(10,0));
SELECT a IN (1,1e0) FROM t1;
a IN (1,1e0)
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a IN (1,1e0,NULL) FROM t1;
a IN (1,1e0,NULL)
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a NOT IN (1,1e0) FROM t1;
a NOT IN (1,1e0)
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a NOT IN (1,1e0,NULL) FROM t1;
a NOT IN (1,1e0,NULL)
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a IN (1,'1') FROM t1;
a IN (1,'1')
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a IN (1,'1',NULL) FROM t1;
a IN (1,'1',NULL)
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a NOT IN (1,'1') FROM t1;
a NOT IN (1,'1')
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a NOT IN (1,'1',NULL) FROM t1;
a NOT IN (1,'1',NULL)
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a IN (1,TIME'10:20:30') FROM t1;
a IN (1,TIME'10:20:30')
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=1 (time)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a IN (1,TIME'10:20:30',NULL) FROM t1;
a IN (1,TIME'10:20:30',NULL)
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=1 (time)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a NOT IN (1,TIME'10:20:30') FROM t1;
a NOT IN (1,TIME'10:20:30')
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=1 (time)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a NOT IN (1,TIME'10:20:30',NULL) FROM t1;
a NOT IN (1,TIME'10:20:30',NULL)
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (decimal)
Note 1105 DBUG: [1] arg=2 handler=1 (time)
Note 1105 DBUG: types_compatible=no bisect=no
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:
Note 1105 DBUG: [0] arg=1 handler=0 (double)
Note 1105 DBUG: [1] arg=2 handler=1 (time)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a IN (1,TIME'10:20:30',NULL) FROM t1;
a IN (1,TIME'10:20:30',NULL)
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (double)
Note 1105 DBUG: [1] arg=2 handler=1 (time)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a NOT IN (1,TIME'10:20:30') FROM t1;
a NOT IN (1,TIME'10:20:30')
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (double)
Note 1105 DBUG: [1] arg=2 handler=1 (time)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a NOT IN (1,TIME'10:20:30',NULL) FROM t1;
a NOT IN (1,TIME'10:20:30',NULL)
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (double)
Note 1105 DBUG: [1] arg=2 handler=1 (time)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a IN (1,DATE'2001-01-01') FROM t1;
a IN (1,DATE'2001-01-01')
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (double)
Note 1105 DBUG: [1] arg=2 handler=1 (date)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a IN (1,DATE'2001-01-01',NULL) FROM t1;
a IN (1,DATE'2001-01-01',NULL)
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (double)
Note 1105 DBUG: [1] arg=2 handler=1 (date)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a NOT IN (1,DATE'2001-01-01') FROM t1;
a NOT IN (1,DATE'2001-01-01')
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (double)
Note 1105 DBUG: [1] arg=2 handler=1 (date)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a NOT IN (1,DATE'2001-01-01',NULL) FROM t1;
a NOT IN (1,DATE'2001-01-01',NULL)
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (double)
Note 1105 DBUG: [1] arg=2 handler=1 (date)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a IN (1,TIMESTAMP'2001-01-01 10:20:30') FROM t1;
a IN (1,TIMESTAMP'2001-01-01 10:20:30')
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (double)
Note 1105 DBUG: [1] arg=2 handler=1 (datetime)
Note 1105 DBUG: types_compatible=no bisect=no
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:
Note 1105 DBUG: [0] arg=1 handler=0 (double)
Note 1105 DBUG: [1] arg=2 handler=1 (datetime)
Note 1105 DBUG: types_compatible=no bisect=no
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:
Note 1105 DBUG: [0] arg=1 handler=0 (double)
Note 1105 DBUG: [1] arg=2 handler=1 (datetime)
Note 1105 DBUG: types_compatible=no bisect=no
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:
Note 1105 DBUG: [0] arg=1 handler=0 (double)
Note 1105 DBUG: [1] arg=2 handler=1 (datetime)
Note 1105 DBUG: types_compatible=no bisect=no
DROP TABLE t1;
CREATE TABLE t1 (a VARCHAR(10));
SELECT a IN ('a',1) FROM t1;
a IN ('a',1)
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (longblob)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a IN ('a',TIME'10:20:30') FROM t1;
a IN ('a',TIME'10:20:30')
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (longblob)
Note 1105 DBUG: [1] arg=2 handler=1 (time)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a NOT IN ('a',1) FROM t1;
a NOT IN ('a',1)
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (longblob)
Note 1105 DBUG: [1] arg=2 handler=1 (double)
Note 1105 DBUG: types_compatible=no bisect=no
SELECT a NOT IN ('a',TIME'10:20:30') FROM t1;
a NOT IN ('a',TIME'10:20:30')
Warnings:
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:
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:
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:
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:
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:
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:
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:
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:
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)
Note 1105 DBUG: types_compatible=no bisect=no
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:
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
Note 1105 DBUG: types_compatible=yes bisect=no
SELECT ROW(a,a) NOT IN ((1,1),(2,2)) FROM t1;
ROW(a,a) NOT IN ((1,1),(2,2))
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
Note 1105 DBUG: types_compatible=yes bisect=no
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:
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
Note 1105 DBUG: types_compatible=yes bisect=no
SELECT ROW(a,a) NOT IN ((1,1),(2,2)) FROM t1;
ROW(a,a) NOT IN ((1,1),(2,2))
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
Note 1105 DBUG: types_compatible=yes bisect=yes
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:
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
Note 1105 DBUG: types_compatible=yes bisect=no
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:
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
Note 1105 DBUG: types_compatible=yes bisect=no
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:
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
Note 1105 DBUG: types_compatible=yes bisect=no
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:
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
Note 1105 DBUG: types_compatible=yes bisect=yes
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:
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
Note 1105 DBUG: types_compatible=yes bisect=no
SELECT ROW(a,a) IN ((1,1),(2,2)) FROM t1;
ROW(a,a) IN ((1,1),(2,2))
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
Note 1105 DBUG: types_compatible=yes bisect=no
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:
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
Note 1105 DBUG: types_compatible=yes bisect=no
SELECT ROW(a,a) IN ((1,1),(2,2)) FROM t1;
ROW(a,a) IN ((1,1),(2,2))
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
Note 1105 DBUG: types_compatible=yes bisect=yes
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:
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
Note 1105 DBUG: types_compatible=yes bisect=no
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:
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
Note 1105 DBUG: types_compatible=yes bisect=no
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:
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
Note 1105 DBUG: types_compatible=yes bisect=no
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:
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
Note 1105 DBUG: types_compatible=yes bisect=yes
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:
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
Note 1105 DBUG: types_compatible=yes bisect=no
SELECT 1 FROM t1 WHERE ROW(a,a) NOT IN ((1,1),(2,2));
1
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
Note 1105 DBUG: types_compatible=yes bisect=no
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:
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
Note 1105 DBUG: types_compatible=yes bisect=no
SELECT 1 FROM t1 WHERE ROW(a,a) NOT IN ((1,1),(2,2));
1
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
Note 1105 DBUG: types_compatible=yes bisect=yes
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:
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
Note 1105 DBUG: types_compatible=yes bisect=no
SELECT 1 FROM t1 WHERE ROW(a,(a,a)) NOT IN ((1,(1,1)),(2,(2,2)));
1
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
Note 1105 DBUG: types_compatible=yes bisect=no
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:
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
Note 1105 DBUG: types_compatible=yes bisect=no
SELECT 1 FROM t1 WHERE ROW(a,(a,a)) NOT IN ((1,(1,1)),(2,(2,2)));
1
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
Note 1105 DBUG: types_compatible=yes bisect=yes
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:
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
Note 1105 DBUG: types_compatible=yes bisect=yes
SELECT 1 FROM t1 WHERE ROW(a,a) IN ((1,1),(2,2));
1
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
Note 1105 DBUG: types_compatible=yes bisect=yes
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:
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
Note 1105 DBUG: types_compatible=yes bisect=yes
SELECT 1 FROM t1 WHERE ROW(a,a) IN ((1,1),(2,2));
1
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
Note 1105 DBUG: types_compatible=yes bisect=yes
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:
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
Note 1105 DBUG: types_compatible=yes bisect=yes
SELECT 1 FROM t1 WHERE ROW(a,(a,a)) IN ((1,(1,1)),(2,(2,2)));
1
Warnings:
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
Note 1105 DBUG: types_compatible=yes bisect=yes
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:
Note 1105 DBUG: [0] arg=1 handler=0 (row)
Note 1105 DBUG: [1] arg=2 handler=0 (row)
Note 1105 DBUG: types_compatible=yes bisect=yes
SELECT 1 FROM t1 WHERE ROW(a,(a,a)) IN ((1,(1,1)),(2,(2,2)));
1
Warnings:
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:
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:
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:
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:
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:
Note 1105 DBUG: [0] arg=2 handler=0 (longblob)
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:
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:
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:
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:
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:
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:
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:
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:
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:
Note 1105 DBUG: [0] arg=1 handler=0 (bigint)
Note 1105 DBUG: [1] arg=2 handler=1 (decimal)
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:
Note 1105 DBUG: [0] arg=1 handler=0 (time)
Note 1105 DBUG: [1] arg=2 handler=0 (time)
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
SET SESSION debug_dbug="-d,Predicant_to_list_comparator";
SET SESSION debug_dbug="-d,Item_func_in";