2016-12-10 22:25:17 +04:00
--source include/have_debug.inc
SET SESSION debug_dbug="+d,Item_func_in";
MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems
This patch fixes a number of data type aggregation problems in IN and CASE:
- MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
- MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
- MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
- MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
1. The problem reported in MDEV-11514 and MDEV-11555 was in the wrong assumption
that items having the same cmp_type() can reuse the same cmp_item instance.
So Item_func_case and Item_func_in used a static array of cmp_item*,
one element per one XXX_RESULT.
TIME and DATETIME cannot reuse the same cmp_item, because arguments of
these types are compared very differently. TIME and DATETIME must have
different instances in the cmp_item array. Reusing the same cmp_item
for TIME and DATETIME leads to unexpected result and unexpected warnings.
Note, after adding more data types soon (e.g. INET6), the problem would
become more serious, as INET6 will most likely have STRING_RESULT, but
it won't be able to reuse the same cmp_item with VARCHAR/TEXT.
This patch introduces a new class Predicant_to_list_comparator,
which maintains an array of cmp_items, one element per distinct
Type_handler rather than one element per XXX_RESULT.
2. The problem reported in MDEV-11497 and MDEV-11554 happened because
Item_func_in and Item_func_case did not take into account the fact
that UNSIGNED and SIGNED values must be compared as DECIMAL rather than INT,
because they used item_cmp_type() to aggregate the arguments.
The relevant code now resides in Predicant_to_list_comparator::add_value()
and uses Type_handler_hybrid_field_type::aggregate_for_comparison(),
like Item_func_between does.
2016-12-17 23:35:12 +04:00
SET SESSION debug_dbug="+d,Predicant_to_list_comparator";
2016-12-10 22:25:17 +04:00
--echo # Constant predicant, compatible types, bisect
SELECT 1 IN (1,2);
SELECT 1 IN (1,2,NULL);
SELECT 1 NOT IN (1,2);
SELECT 1 NOT IN (1,2,NULL);
SELECT 1.0 IN (1.0,2.0);
SELECT 1.0 IN (1.0,2.0,NULL);
SELECT 1.0 NOT IN (1.0,2.0);
SELECT 1.0 NOT IN (1.0,2.0,NULL);
SELECT 1e0 IN (1e0,2e0);
SELECT 1e0 IN (1e0,2e0,NULL);
SELECT 1e0 NOT IN (1e0,2e0);
SELECT 1e0 NOT IN (1e0,2e0,NULL);
SELECT 'a' IN ('a','b');
SELECT 'a' IN ('a','b',NULL);
SELECT 'a' NOT IN ('a','b');
SELECT 'a' NOT IN ('a','b',NULL);
2023-10-13 11:15:14 +02:00
SELECT TIMESTAMP'2001-01-01 10:20:30' IN ('2001-01-01 10:20:30','2001-02-02 10:20:30') as exp;
SELECT TIMESTAMP'2001-01-01 10:20:30' IN ('2001-01-01 10:20:30','2001-02-02 10:20:30',NULL) as exp;
SELECT TIMESTAMP'2001-01-01 10:20:30' NOT IN ('2001-01-01 10:20:30','2001-02-02 10:20:30') as exp;
SELECT TIMESTAMP'2001-01-01 10:20:30' NOT IN ('2001-01-01 10:20:30','2001-02-02 10:20:30',NULL) as exp;
2022-06-09 10:32:51 +07:00
2016-12-10 22:25:17 +04:00
SELECT TIME'10:20:30' IN ('10:20:30','10:20:30');
SELECT TIME'10:20:30' IN ('10:20:30','10:20:30',NULL);
SELECT TIME'10:20:30' NOT IN ('10:20:30','10:20:30');
SELECT TIME'10:20:30' NOT IN ('10:20:30','10:20:30',NULL);
SELECT DATE'2001-01-01' IN ('2001-01-01','2001-02-02');
SELECT DATE'2001-01-01' IN ('2001-01-01','2001-02-02',NULL);
SELECT DATE'2001-01-01' NOT IN ('2001-01-01','2001-02-02');
SELECT DATE'2001-01-01' NOT IN ('2001-01-01','2001-02-02',NULL);
--echo # 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
# Special case: mixture of unsigned, signed and decimal
CREATE TABLE t1 (a INT UNSIGNED);
# a=1.0 is done as decimal, because decimal bits int
# a=1 is done as decimal as well, because of different unsigned flag
SELECT a IN (1.0, 1) FROM t1;
DROP TABLE t1;
2016-12-10 22:25:17 +04:00
CREATE TABLE t1 (a INT);
SELECT a IN (1,2,3) FROM t1;
SELECT a IN (1,2,3,NULL) FROM 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
SELECT a IN (1.0, CAST(1 AS UNSIGNED)) FROM t1;
SELECT a IN (1.0, CAST(1 AS UNSIGNED),NULL) FROM t1;
2016-12-10 22:25:17 +04:00
SELECT a NOT IN (1,2,3) FROM t1;
SELECT a NOT IN (1,2,3,NULL) FROM 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
SELECT a NOT IN (1.0, CAST(1 AS UNSIGNED)) FROM t1;
SELECT a NOT IN (1.0, CAST(1 AS UNSIGNED),NULL) FROM t1;
2016-12-10 22:25:17 +04:00
DROP TABLE t1;
CREATE TABLE t1 (a DOUBLE);
SELECT a IN (1e0,2,3.0) FROM t1;
SELECT a IN (1e0,2,3.0,NULL) FROM t1;
SELECT a NOT IN (1e0,2,3.0) FROM t1;
SELECT a NOT IN (1e0,2,3.0,NULL) FROM t1;
DROP TABLE t1;
CREATE TABLE t1 (a DECIMAL(10,1));
SELECT a IN (1,2.0,3.0) FROM t1;
SELECT a IN (1,2.0,3.0,NULL) FROM t1;
SELECT a NOT IN (1,2.0,3.0) FROM t1;
SELECT a NOT IN (1,2.0,3.0,NULL) FROM t1;
DROP TABLE t1;
CREATE TABLE t1 (a VARCHAR(10));
SELECT a IN ('a','b','c') FROM t1;
SELECT a IN ('a','b','c',NULL) FROM t1;
SELECT a NOT IN ('a','b','c') FROM t1;
SELECT a NOT IN ('a','b','c',NULL) FROM t1;
DROP TABLE t1;
CREATE TABLE t1 (a DATE);
2023-10-13 11:15:14 +02:00
SELECT a IN ('2001-01-01',DATE'2001-01-02',20010102,20010102.0,20010102e0) as exp FROM t1;
SELECT a IN ('2001-01-01',DATE'2001-01-02',20010102,20010102.0,20010102e0,NULL) as exp FROM t1;
SELECT a NOT IN ('2001-01-01',DATE'2001-01-02',20010102,20010102.0,20010102e0) as exp FROM t1;
SELECT a NOT IN ('2001-01-01',DATE'2001-01-02',20010102,20010102.0,20010102e0,NULL) as exp FROM t1;
2016-12-10 22:25:17 +04:00
DROP TABLE t1;
CREATE TABLE t1 (a TIME);
2023-10-13 11:15:14 +02:00
SELECT a IN ('10:20:30',TIME'10:20:30',102030,102030.0,102030e0) as exp FROM t1;
SELECT a IN ('10:20:30',TIME'10:20:30',102030,102030.0,102030e0,NULL) as exp FROM t1;
SELECT a NOT IN ('10:20:30',TIME'10:20:30',102030,102030.0,102030e0) as exp FROM t1;
SELECT a NOT IN ('10:20:30',TIME'10:20:30',102030,102030.0,102030e0,NULL) as exp FROM t1;
2016-12-10 22:25:17 +04:00
DROP TABLE t1;
CREATE TABLE t1 (a DATETIME);
2023-10-13 11:15:14 +02:00
SELECT a IN ('2001-01-01',TIMESTAMP'2001-01-01 10:20:30',DATE'2001-01-01',TIME'10:20:30',20010101102030,20010101102030.0,20010101102030e0) as exp FROM t1;
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) as exp FROM t1;
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) as exp FROM t1;
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) as exp FROM t1;
2016-12-10 22:25:17 +04:00
DROP TABLE t1;
--echo # Constant predicant, compatible types, no bisect
--echo # 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;
SELECT 1 IN (a,1,2,3,NULL) FROM t1;
SELECT 1 NOT IN (a,1,2,3) FROM t1;
SELECT 1 NOT IN (a,1,2,3,NULL) FROM t1;
DROP TABLE t1;
CREATE TABLE t1 (a DOUBLE);
SELECT 1 IN (a,1e0,2e0,3e0) FROM t1;
SELECT 1 IN (a,1e0,2e0,3e0,NULL) FROM t1;
SELECT 1 NOT IN (a,1e0,2e0,3e0) FROM t1;
SELECT 1 NOT IN (a,1e0,2e0,3e0,NULL) FROM t1;
DROP TABLE t1;
CREATE TABLE t1 (a DECIMAL(10,1));
SELECT 1 IN (a,1.0,2.0,3.0) FROM t1;
SELECT 1 IN (a,1.0,2.0,3.0,NULL) FROM t1;
SELECT 1 NOT IN (a,1.0,2.0,3.0) FROM t1;
SELECT 1 NOT IN (a,1.0,2.0,3.0,NULL) FROM t1;
DROP TABLE t1;
CREATE TABLE t1 (a VARCHAR(10));
SELECT 'a' IN (a,'b','c') FROM t1;
SELECT 'a' IN (a,'b','c',NULL) FROM t1;
SELECT 'a' NOT IN (a,'b','c') FROM t1;
SELECT 'a' NOT IN (a,'b','c',NULL) FROM t1;
DROP TABLE t1;
CREATE TABLE t1 (a DATE);
SELECT DATE'2001-01-01' IN (a,'2001-01-01') FROM t1;
SELECT DATE'2001-01-01' IN (a,'2001-01-01',NULL) FROM t1;
SELECT DATE'2001-01-01' NOT IN (a,'2001-01-01') FROM t1;
SELECT DATE'2001-01-01' NOT IN (a,'2001-01-01',NULL) FROM t1;
DROP TABLE t1;
CREATE TABLE t1 (a TIME);
SELECT TIME'10:20:30' IN (a,'10:20:30') FROM t1;
SELECT TIME'10:20:30' IN (a,'10:20:30',NULL) FROM t1;
SELECT TIME'10:20:30' NOT IN (a,'10:20:30') FROM t1;
SELECT TIME'10:20:30' NOT IN (a,'10:20:30',NULL) FROM t1;
DROP TABLE t1;
CREATE TABLE t1 (a DATETIME);
2023-10-13 11:15:14 +02:00
SELECT TIMESTAMP'2001-01-01 10:20:30' IN (a,TIMESTAMP'2001-01-01 10:20:30') as exp FROM t1;
SELECT TIMESTAMP'2001-01-01 10:20:30' IN (a,TIMESTAMP'2001-01-01 10:20:30',NULL) as exp FROM t1;
SELECT TIMESTAMP'2001-01-01 10:20:30' NOT IN (a,TIMESTAMP'2001-01-01 10:20:30') as exp FROM t1;
SELECT TIMESTAMP'2001-01-01 10:20:30' NOT IN (a,TIMESTAMP'2001-01-01 10:20:30',NULL) as exp FROM t1;
2016-12-10 22:25:17 +04:00
DROP TABLE t1;
--echo # Constant predicant, incompatible types, no bisect
SELECT 1 IN (1,2e0);
SELECT 1 IN (1,2e0,NULL);
SELECT 1 NOT IN (1,2e0);
SELECT 1 NOT IN (1,2e0,NULL);
SELECT 1.0 IN (1.0,2e0);
SELECT 1.0 IN (1.0,2e0,NULL);
SELECT 1.0 NOT IN (1.0,2e0);
SELECT 1.0 NOT IN (1.0,2e0,NULL);
SELECT 1e0 IN (1.0,TIME'10:20:30');
SELECT 1e0 IN (1.0,TIME'10:20:30',NULL);
SELECT 1e0 NOT IN (1.0,TIME'10:20:30');
SELECT 1e0 NOT IN (1.0,TIME'10:20:30',NULL);
SELECT 'a' IN ('a',2);
SELECT 'a' IN ('a',2,NULL);
SELECT 'a' NOT IN ('a',2);
SELECT 'a' NOT IN ('a',2,NULL);
2023-10-13 11:15:14 +02:00
SELECT TIME'10:20:30' IN (1,TIME'10:20:30') as exp;
SELECT TIME'10:20:30' IN (1,TIME'10:20:30',NULL) as exp;
SELECT TIME'10:20:30' IN (102030, TIME'10:20:30',TIMESTAMP'2001-01-01 10:20:32') as exp;
SELECT TIME'10:20:30' IN (102030, TIME'10:20:30',TIMESTAMP'2001-01-01 10:20:32',NULL) as exp;
SELECT TIME'10:20:30' IN (102030, 102030, TIME'10:20:30',TIMESTAMP'2001-01-01 10:20:32') as exp;
SELECT TIME'10:20:30' IN (102030, 102030, TIME'10:20:30',TIMESTAMP'2001-01-01 10:20:32',NULL) as exp;
SELECT TIME'10:20:30' NOT IN (1,TIME'10:20:30') as exp;
SELECT TIME'10:20:30' NOT IN (1,TIME'10:20:30',NULL) as exp;
SELECT TIME'10:20:30' NOT IN (102030, TIME'10:20:30',TIMESTAMP'2001-01-01 10:20:32') as exp;
SELECT TIME'10:20:30' NOT IN (102030, TIME'10:20:30',TIMESTAMP'2001-01-01 10:20:32',NULL) as exp;
SELECT TIME'10:20:30' NOT IN (102030, 102030, TIME'10:20:30',TIMESTAMP'2001-01-01 10:20:32') as exp;
SELECT TIME'10:20:30' NOT IN (102030, 102030, TIME'10:20:30',TIMESTAMP'2001-01-01 10:20:32',NULL) as exp;
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
2016-12-10 22:25:17 +04:00
--echo # Column predicant, incompatible types, no bisect
CREATE TABLE t1 (a INT);
SELECT a IN (1,1e0) FROM t1;
SELECT a IN (1,1e0,NULL) FROM t1;
2023-10-13 11:15:14 +02:00
SELECT a IN (CAST(1 AS SIGNED), CAST(1 AS UNSIGNED)) as exp FROM t1;
SELECT a IN (CAST(1 AS SIGNED), CAST(1 AS UNSIGNED),NULL) as exp FROM t1;
SELECT a IN (CAST(1 AS DECIMAL),CAST(1 AS SIGNED), CAST(1 AS UNSIGNED)) as exp FROM t1;
SELECT a IN (CAST(1 AS DECIMAL),CAST(1 AS SIGNED), CAST(1 AS UNSIGNED),NULL) as exp FROM t1;
2016-12-10 22:25:17 +04:00
SELECT a NOT IN (1,1e0) FROM t1;
SELECT a NOT IN (1,1e0,NULL) FROM t1;
2023-10-13 11:15:14 +02:00
SELECT a NOT IN (CAST(1 AS SIGNED), CAST(1 AS UNSIGNED)) as exp FROM t1;
SELECT a NOT IN (CAST(1 AS SIGNED), CAST(1 AS UNSIGNED),NULL) as exp FROM t1;
SELECT a NOT IN (CAST(1 AS DECIMAL),CAST(1 AS SIGNED), CAST(1 AS UNSIGNED)) as exp FROM t1;
SELECT a NOT IN (CAST(1 AS DECIMAL),CAST(1 AS SIGNED), CAST(1 AS UNSIGNED),NULL) as exp FROM t1;
2022-06-09 10:32:51 +07:00
2016-12-10 22:25:17 +04:00
SELECT a IN (1,1.0) FROM t1;
SELECT a IN (1,1.0,NULL) FROM t1;
SELECT a NOT IN (1,1.0) FROM t1;
SELECT a NOT IN (1,1.0,NULL) FROM t1;
SELECT a IN (1,'1') FROM t1;
SELECT a IN (1,'1',NULL) FROM t1;
SELECT a NOT IN (1,'1') FROM t1;
SELECT a NOT IN (1,'1',NULL) FROM t1;
SELECT a IN (1,TIME'10:20:30') FROM t1;
SELECT a IN (1,TIME'10:20:30',NULL) FROM t1;
SELECT a NOT IN (1,TIME'10:20:30') FROM t1;
SELECT a NOT IN (1,TIME'10:20:30',NULL) FROM t1;
DROP TABLE t1;
CREATE TABLE t1 (a DECIMAL(10,0));
SELECT a IN (1,1e0) FROM t1;
SELECT a IN (1,1e0,NULL) FROM t1;
SELECT a NOT IN (1,1e0) FROM t1;
SELECT a NOT IN (1,1e0,NULL) FROM t1;
SELECT a IN (1,'1') FROM t1;
SELECT a IN (1,'1',NULL) FROM t1;
SELECT a NOT IN (1,'1') FROM t1;
SELECT a NOT IN (1,'1',NULL) FROM t1;
SELECT a IN (1,TIME'10:20:30') FROM t1;
SELECT a IN (1,TIME'10:20:30',NULL) FROM t1;
SELECT a NOT IN (1,TIME'10:20:30') FROM t1;
SELECT a NOT IN (1,TIME'10:20:30',NULL) FROM t1;
DROP TABLE t1;
CREATE TABLE t1 (a DOUBLE);
SELECT a IN (1,TIME'10:20:30') FROM t1;
SELECT a IN (1,TIME'10:20:30',NULL) FROM t1;
SELECT a NOT IN (1,TIME'10:20:30') FROM t1;
SELECT a NOT IN (1,TIME'10:20:30',NULL) FROM t1;
SELECT a IN (1,DATE'2001-01-01') FROM t1;
SELECT a IN (1,DATE'2001-01-01',NULL) FROM t1;
SELECT a NOT IN (1,DATE'2001-01-01') FROM t1;
SELECT a NOT IN (1,DATE'2001-01-01',NULL) FROM t1;
SELECT a IN (1,TIMESTAMP'2001-01-01 10:20:30') FROM t1;
SELECT a IN (1,TIMESTAMP'2001-01-01 10:20:30',NULL) FROM t1;
SELECT a NOT IN (1,TIMESTAMP'2001-01-01 10:20:30') FROM t1;
SELECT a NOT IN (1,TIMESTAMP'2001-01-01 10:20:30',NULL) FROM t1;
DROP TABLE t1;
CREATE TABLE t1 (a VARCHAR(10));
SELECT a IN ('a',1) FROM t1;
SELECT a IN ('a',TIME'10:20:30') FROM t1;
SELECT a NOT IN ('a',1) FROM t1;
SELECT a NOT IN ('a',TIME'10:20:30') FROM t1;
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
CREATE TABLE t1 (a TIME);
2023-10-13 11:15:14 +02:00
SELECT a IN (102030, TIME'10:20:30',TIMESTAMP'2001-01-01 10:20:32') as exp FROM t1;
SELECT a IN (102030, TIME'10:20:30',TIMESTAMP'2001-01-01 10:20:32',NULL) as exp FROM t1;
SELECT a IN (102030, 102030, TIME'10:20:30',TIMESTAMP'2001-01-01 10:20:32') as exp FROM t1;
SELECT a IN (102030, 102030, TIME'10:20:30',TIMESTAMP'2001-01-01 10:20:32',NULL) as exp FROM t1;
SELECT a NOT IN (102030, TIME'10:20:30',TIMESTAMP'2001-01-01 10:20:32') as exp FROM t1;
SELECT a NOT IN (102030, TIME'10:20:30',TIMESTAMP'2001-01-01 10:20:32',NULL) as exp FROM t1;
SELECT a NOT IN (102030, 102030, TIME'10:20:30',TIMESTAMP'2001-01-01 10:20:32') as exp FROM t1;
SELECT a NOT IN (102030, 102030, TIME'10:20:30',TIMESTAMP'2001-01-01 10:20:32',NULL) as exp FROM 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
DROP TABLE t1;
2016-12-10 22:25:17 +04:00
#
# ROW tests
#
# ROW has additional conditions when bisect is possible (see item_cmpfunc.h):
#
# ((is_top_level_item && not_negated) || // 3
# (arg0_can_not_be_null && list_does_not_have_nulls) // 4
# Testing all combinations of the condition components
#
# tli - is_top_level_item
# nneg - not_negated
# a0nnul - arg0_can_not_be_null
# lnnul - list_does_not_have_nulls
# cond3 - condition 3 is true?
# cond4 - condition 4 is true?
# bisect - bisect is possible (cond3 orded with cond4)
# Note:
# - using an expression in SELECT list makes top_level_item() to be false
# - using an expression in WHERE clause makes top_leve_item() to be true
--echo # Not top level, negated: cond3 is false
# tli nneg a0nnul lnnul cond3 cond4 bisect
# --- --- ------ ----- ----- ----- ------
# 0 0 0 0 0 0 0
# 0 0 0 1 0 0 0
# 0 0 1 0 0 0 0
# 0 0 1 1 0 1 1
# ROW with scalar elements
CREATE TABLE t1 (a INT);
SELECT ROW(a,a) NOT IN ((1,1),(2,NULL)) FROM t1;
SELECT ROW(a,a) NOT IN ((1,1),(2,2)) FROM t1;
DROP TABLE t1;
CREATE TABLE t1 (a INT NOT NULL, b INT);
SELECT ROW(a,a) NOT IN ((1,1),(2,NULL)) FROM t1;
SELECT ROW(a,a) NOT IN ((1,1),(2,2)) FROM t1;
DROP TABLE t1;
# ROW with a nested ROW
CREATE TABLE t1 (a INT);
SELECT ROW(a,(a,a)) NOT IN ((1,(1,1)),(2,(2,NULL))) FROM t1;
SELECT ROW(a,(a,a)) NOT IN ((1,(1,1)),(2,(2,2))) FROM t1;
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;
SELECT ROW(a,(a,a)) NOT IN ((1,(1,1)),(2,(2,2))) FROM t1;
DROP TABLE t1;
--echo # Not top level, not negated: cond3 is false
# tli nneg a0nnul lnnul cond3 cond4 bisect
# --- --- ------ ----- ----- ----- ------
# 0 1 0 0 0 0 0
# 0 1 0 1 0 0 0
# 0 1 1 0 0 0 0
# 0 1 1 1 0 1 1
# ROW with scalar elements
CREATE TABLE t1 (a INT);
SELECT ROW(a,a) IN ((1,1),(2,NULL)) FROM t1;
SELECT ROW(a,a) IN ((1,1),(2,2)) FROM t1;
DROP TABLE t1;
CREATE TABLE t1 (a INT NOT NULL);
SELECT ROW(a,a) IN ((1,1),(2,NULL)) FROM t1;
SELECT ROW(a,a) IN ((1,1),(2,2)) FROM t1;
DROP TABLE t1;
# ROW with a nested ROW
CREATE TABLE t1 (a INT);
SELECT ROW(a,(a,a)) IN ((1,(1,1)),(2,(2,NULL))) FROM t1;
SELECT ROW(a,(a,a)) IN ((1,(1,1)),(2,(2,2))) FROM t1;
DROP TABLE t1;
CREATE TABLE t1 (a INT NOT NULL);
SELECT ROW(a,(a,a)) IN ((1,(1,1)),(2,(2,NULL))) FROM t1;
SELECT ROW(a,(a,a)) IN ((1,(1,1)),(2,(2,2))) FROM t1;
DROP TABLE t1;
--echo # Top level, negated: cond3 is false
# tli nneg a0nnul lnnul cond3 cond4 bisect
# --- --- ------ ----- ----- ----- ------
# 1 0 0 0 0 0 0
# 1 0 0 1 0 0 0
# 1 0 1 0 0 0 0
# 1 0 1 1 0 1 1
# ROW with scalar elements
CREATE TABLE t1 (a INT);
SELECT 1 FROM t1 WHERE ROW(a,a) NOT IN ((1,1),(2,NULL));
SELECT 1 FROM t1 WHERE ROW(a,a) NOT IN ((1,1),(2,2));
DROP TABLE t1;
CREATE TABLE t1 (a INT NOT NULL);
SELECT 1 FROM t1 WHERE ROW(a,a) NOT IN ((1,1),(2,NULL));
SELECT 1 FROM t1 WHERE ROW(a,a) NOT IN ((1,1),(2,2));
DROP TABLE t1;
# ROW with a nested ROW
CREATE TABLE t1 (a INT);
SELECT 1 FROM t1 WHERE ROW(a,(a,a)) NOT IN ((1,(1,1)),(2,(2,NULL)));
SELECT 1 FROM t1 WHERE ROW(a,(a,a)) NOT IN ((1,(1,1)),(2,(2,2)));
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)));
SELECT 1 FROM t1 WHERE ROW(a,(a,a)) NOT IN ((1,(1,1)),(2,(2,2)));
DROP TABLE t1;
--echo # Top level, not negated: cond3 is true
# tli nneg a0nnul lnnul cond3 cond4 bisect
# --- --- ------ ----- ----- ----- ------
# 1 1 0 0 1 0 1
# 1 1 0 1 1 1 1
# 1 1 1 0 1 0 1
# 1 1 1 1 1 1 1
# ROW with scalar elements
CREATE TABLE t1 (a INT);
SELECT 1 FROM t1 WHERE ROW(a,a) IN ((1,1),(2,NULL));
SELECT 1 FROM t1 WHERE ROW(a,a) IN ((1,1),(2,2));
DROP TABLE t1;
CREATE TABLE t1 (a INT NOT NULL);
SELECT 1 FROM t1 WHERE ROW(a,a) IN ((1,1),(2,NULL));
SELECT 1 FROM t1 WHERE ROW(a,a) IN ((1,1),(2,2));
DROP TABLE t1;
# ROW with a nested ROW
CREATE TABLE t1 (a INT);
SELECT 1 FROM t1 WHERE ROW(a,(a,a)) IN ((1,(1,1)),(2,(2,NULL)));
SELECT 1 FROM t1 WHERE ROW(a,(a,a)) IN ((1,(1,1)),(2,(2,2)));
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)));
SELECT 1 FROM t1 WHERE ROW(a,(a,a)) IN ((1,(1,1)),(2,(2,2)));
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
--echo #
--echo # MDEV-11514 IN with a mixture of TIME and DATETIME returns a wrong result
--echo #
2016-12-10 22:25:17 +04:00
2023-10-13 11:15:14 +02:00
SELECT TIME'10:20:30' IN (102030,TIME'10:20:31',TIMESTAMP'2001-01-01 10:20:32') as exp;
2022-06-09 10:32:51 +07:00
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
PREPARE stmt FROM "SELECT
TIME'10:20:30' IN (102030,TIME'10:20:31',TIMESTAMP'2001-01-01 10:20:32')";
EXECUTE stmt;
EXECUTE stmt;
DEALLOCATE PREPARE stmt;
CREATE TABLE t1 (a VARCHAR(10));
INSERT INTO t1 VALUES ('A'),('B'),('A');
# Compatible types
SELECT a,NULL AS b FROM t1 GROUP BY a HAVING 'A' IN (b,'A');
SELECT a,NULL AS b FROM t1 GROUP BY a HAVING 'A' IN ('A',b);
SELECT a,NULL AS b FROM t1 GROUP BY a HAVING 'A' IN (b,a);
SELECT a,NULL AS b FROM t1 GROUP BY a HAVING 'A' IN (a,b);
# Incompatible types
SELECT a,NULL AS b FROM t1 GROUP BY a HAVING 'A' IN (b,'A',10);
SELECT a,NULL AS b FROM t1 GROUP BY a HAVING 'A' IN ('A',b,10);
SELECT a,NULL AS b FROM t1 GROUP BY a HAVING 'A' IN (b,a,10);
SELECT a,NULL AS b FROM t1 GROUP BY a HAVING 'A' IN (a,b,10);
DROP TABLE t1;
--echo #
--echo # MDEV-11497 Wrong result for (int_expr IN (mixture of signed and unsigned expressions))
--echo #
CREATE TABLE t1 (a BIGINT, b BIGINT UNSIGNED);
INSERT INTO t1 VALUES (-9223372036854775808,18446744073709551615);
SELECT * FROM t1 WHERE -1 IN (a,b);
DROP TABLE t1;
--echo #
--echo # MDEV-11554 Wrong result for CASE on a mixture of signed and unsigned expressions
--echo #
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;
DROP TABLE t1;
--echo #
--echo # MDEV-11555 CASE with a mixture of TIME and DATETIME returns a wrong result
--echo #
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;
SET SESSION debug_dbug="-d,Predicant_to_list_comparator";
2016-12-10 22:25:17 +04:00
SET SESSION debug_dbug="-d,Item_func_in";
2018-06-05 22:26:24 +04:00
2019-03-21 13:43:17 +04:00
--echo #
--echo # MDEV-19008 Slow EXPLAIN SELECT ... WHERE col IN (const1,const2,(subquery))
--echo #
SET SESSION debug_dbug="+d,Item_subselect";
CREATE TABLE t1 (a INT);
INSERT INTO t1 VALUES (0),(1),(2),(3),(4),(5),(6),(7),(8),(9);
EXPLAIN SELECT * FROM t1 WHERE a IN (1,2,(SELECT MAX(a) FROM t1));
SELECT * FROM t1 WHERE a IN (1,2,(SELECT MAX(a) FROM t1));
DROP TABLE t1;
SET SESSION debug_dbug="-d,Item_subselect";
2019-03-22 13:20:44 +02:00
2018-06-05 22:26:24 +04:00
--echo #
--echo # MDEV-16408 Remove tests for Item::type() in Item_basic_value::eq()
--echo #
SET SESSION debug_dbug="+d,Item_basic_value";
CREATE TABLE t1 (a INT);
INSERT INTO t1 VALUES (1),(2),(3);
SELECT * FROM t1 WHERE a BETWEEN 1 AND 1.0;
SELECT * FROM t1 WHERE a BETWEEN 1 AND 1;
SELECT * FROM t1 WHERE a BETWEEN 0 AND 1;
SELECT * FROM t1 WHERE a BETWEEN 0 AND -1;
SELECT * FROM t1 WHERE a BETWEEN -1 AND -1;
2022-09-15 18:30:13 +07:00
#enable after fix MDEV-29524
--disable_view_protocol
2018-06-05 22:26:24 +04:00
SELECT * FROM t1 WHERE a BETWEEN -0000000000000001 AND -1;
2022-09-15 18:30:13 +07:00
--enable_view_protocol
2018-06-05 22:26:24 +04:00
SELECT * FROM t1 WHERE a BETWEEN -1 AND 18446744073709551615;
SELECT * FROM t1 WHERE a BETWEEN -1 AND 18446744073709551616;
SELECT * FROM t1 WHERE a BETWEEN 1e2 AND 100e0;
EXECUTE IMMEDIATE 'SELECT * FROM t1 WHERE a BETWEEN 1 AND ?' USING 1;
EXECUTE IMMEDIATE 'SELECT * FROM t1 WHERE a BETWEEN -1 AND ?' USING 18446744073709551615;
EXECUTE IMMEDIATE 'SELECT * FROM t1 WHERE a BETWEEN -1 AND ?' USING 18446744073709551616;
DROP TABLE t1;
MDEV-11361 Equal condition propagation does not work for DECIMAL and temporal dynamic SQL parameters
MDEV-16426 Optimizer erroneously treats equal constants of different formats as same
A cleanup for MDEV-14630: fixing a crash in Item_decimal::eq().
Problems:
- old implementations of Item_decimal::eq() and
Item_temporal_literal::eq() were not symmetric
with Item_param::eq(), this caused MDEV-11361.
- old implementations for DECIMAL and temporal data types
did not take into account that in case when eq() is called
with binary_cmp==true, {{eq()}} should check not only equality
of the two values, but also equality if their decimal precision.
This cuases MDEV-16426.
- Item_decimal::eq() crashes with "item" pointing
to a non-DECIMAL value. Before MDEV-14630
non-DECIMAL values were filtered out by the test:
type() == item->type()
as literals of different types had different type().
After MDEV-14630 type() for literals of all data types return CONST_ITEM.
This caused failures in tests:
./mtr engines/iuds.insert_number
./mtr --ps --embedded main.explain_slowquerylog
(revealed by buildbot)
The essence of the fix:
Making literals and Item_param reuse the same code to avoid
asymmetries between Item_param::eq(Item_literal) and
Item_literal::eq(Item_param), now and in the future, and to
avoid code duplication between Item_literal and Item_param.
Adding tests for "decimals" for DECIMAL and temporal data types,
to treat constants of different scale as not equal when "binary_cmp"
is "true".
Details:
1. Adding a helper class Item_const to extract constant values from Items easier
2. Deriving Item_basic_value from Item_const
3. Joining Type_handler::Item_basic_value_eq() and Item_basic_value_bin_eq()
into a single method with an extra "binary_cmp" argument
(it looks simple this way) and renaming the new method to Item_const_eq().
Modifying its implementations to operate with
Item_const instead of Item_basic_value.
4. Adding a new class Type_handler_hex_hybrid,
to handle hex constants like 0x616263.
5. Removing Item::VARBIN_ITEM and fixing Item_hex_constant to
use type_handler_hex_hybrid instead of type_handler_varchar.
Item_hex_hybrid::type() now returns CONST_ITEM, like all
other literals do.
6. Move virtual methods Item::type_handler_for_system_time() and
Item::cast_to_int_type_handler() from Item to Type_handler.
7. Removing Item_decimal::eq() and Item_temporal_literal::eq().
These classes are now handled by the generic Item_basic_value::eq().
8. Implementing Type_handler_temporal_result::Item_const_eq()
and Type_handler_decimal_result::Item_const_eq(),
this fixes MDEV-11361.
9. Adding tests for "decimals" into
Type_handler_decimal_result::Item_const_eq() and
Type_handler_temporal_result::Item_const_eq()
in case if "binary_cmp" is true.
This fixes MDEV-16426.
10. Moving Item_cache out of Item_basic_value.
They share nothing. It simplifies implementation
of Item_basic_value::eq(). Deriving Item_cache
directly from Item.
11. Adding class DbugStringItemTypeValue, which
used Item::print() internally, and using
in instead of the old debug printing code.
This gives nicer output in func_debug.result.
Changes N5 and N6 do not directly relate to the bugs fixed,
but make the code fully symmetric across all literal types.
Without a new handler Type_handler_hex_hybrid we'd have
to keep two code branches (for regular literals and for
hex hybrid literals).
2018-06-08 12:36:42 +04:00
CREATE TABLE t1 (a VARCHAR(10));
INSERT INTO t1 VALUES ('0'),('1'),('2');
SELECT * FROM t1 WHERE a BETWEEN '0' AND '0';
SELECT * FROM t1 WHERE a BETWEEN '0' AND ' 0';
SELECT * FROM t1 WHERE a BETWEEN '0' AND '0 ';
DROP TABLE t1;
SET SESSION debug_dbug="-d,Item_basic_value";
--echo #
--echo # MDEV-11362 True condition elimination does not work for DECIMAL and temporal dynamic SQL parameters
--echo #
SET SESSION debug_dbug="+d,Item_basic_value";
2018-06-05 22:26:24 +04:00
CREATE TABLE t1 (a DECIMAL(10,3));
INSERT INTO t1 VALUES (1),(2),(3);
SELECT * FROM t1 WHERE a BETWEEN 1.0 AND 1.0;
MDEV-11361 Equal condition propagation does not work for DECIMAL and temporal dynamic SQL parameters
MDEV-16426 Optimizer erroneously treats equal constants of different formats as same
A cleanup for MDEV-14630: fixing a crash in Item_decimal::eq().
Problems:
- old implementations of Item_decimal::eq() and
Item_temporal_literal::eq() were not symmetric
with Item_param::eq(), this caused MDEV-11361.
- old implementations for DECIMAL and temporal data types
did not take into account that in case when eq() is called
with binary_cmp==true, {{eq()}} should check not only equality
of the two values, but also equality if their decimal precision.
This cuases MDEV-16426.
- Item_decimal::eq() crashes with "item" pointing
to a non-DECIMAL value. Before MDEV-14630
non-DECIMAL values were filtered out by the test:
type() == item->type()
as literals of different types had different type().
After MDEV-14630 type() for literals of all data types return CONST_ITEM.
This caused failures in tests:
./mtr engines/iuds.insert_number
./mtr --ps --embedded main.explain_slowquerylog
(revealed by buildbot)
The essence of the fix:
Making literals and Item_param reuse the same code to avoid
asymmetries between Item_param::eq(Item_literal) and
Item_literal::eq(Item_param), now and in the future, and to
avoid code duplication between Item_literal and Item_param.
Adding tests for "decimals" for DECIMAL and temporal data types,
to treat constants of different scale as not equal when "binary_cmp"
is "true".
Details:
1. Adding a helper class Item_const to extract constant values from Items easier
2. Deriving Item_basic_value from Item_const
3. Joining Type_handler::Item_basic_value_eq() and Item_basic_value_bin_eq()
into a single method with an extra "binary_cmp" argument
(it looks simple this way) and renaming the new method to Item_const_eq().
Modifying its implementations to operate with
Item_const instead of Item_basic_value.
4. Adding a new class Type_handler_hex_hybrid,
to handle hex constants like 0x616263.
5. Removing Item::VARBIN_ITEM and fixing Item_hex_constant to
use type_handler_hex_hybrid instead of type_handler_varchar.
Item_hex_hybrid::type() now returns CONST_ITEM, like all
other literals do.
6. Move virtual methods Item::type_handler_for_system_time() and
Item::cast_to_int_type_handler() from Item to Type_handler.
7. Removing Item_decimal::eq() and Item_temporal_literal::eq().
These classes are now handled by the generic Item_basic_value::eq().
8. Implementing Type_handler_temporal_result::Item_const_eq()
and Type_handler_decimal_result::Item_const_eq(),
this fixes MDEV-11361.
9. Adding tests for "decimals" into
Type_handler_decimal_result::Item_const_eq() and
Type_handler_temporal_result::Item_const_eq()
in case if "binary_cmp" is true.
This fixes MDEV-16426.
10. Moving Item_cache out of Item_basic_value.
They share nothing. It simplifies implementation
of Item_basic_value::eq(). Deriving Item_cache
directly from Item.
11. Adding class DbugStringItemTypeValue, which
used Item::print() internally, and using
in instead of the old debug printing code.
This gives nicer output in func_debug.result.
Changes N5 and N6 do not directly relate to the bugs fixed,
but make the code fully symmetric across all literal types.
Without a new handler Type_handler_hex_hybrid we'd have
to keep two code branches (for regular literals and for
hex hybrid literals).
2018-06-08 12:36:42 +04:00
EXECUTE IMMEDIATE 'SELECT * FROM t1 WHERE a BETWEEN 1.0 AND ?' USING 1.0;
2018-06-05 22:26:24 +04:00
DROP TABLE t1;
CREATE TABLE t1 (a TIME);
INSERT INTO t1 VALUES ('00:00:00'),('00:00:01');
SELECT * FROM t1 WHERE a BETWEEN TIME'00:00:00' AND TIME'00:00:00';
MDEV-11361 Equal condition propagation does not work for DECIMAL and temporal dynamic SQL parameters
MDEV-16426 Optimizer erroneously treats equal constants of different formats as same
A cleanup for MDEV-14630: fixing a crash in Item_decimal::eq().
Problems:
- old implementations of Item_decimal::eq() and
Item_temporal_literal::eq() were not symmetric
with Item_param::eq(), this caused MDEV-11361.
- old implementations for DECIMAL and temporal data types
did not take into account that in case when eq() is called
with binary_cmp==true, {{eq()}} should check not only equality
of the two values, but also equality if their decimal precision.
This cuases MDEV-16426.
- Item_decimal::eq() crashes with "item" pointing
to a non-DECIMAL value. Before MDEV-14630
non-DECIMAL values were filtered out by the test:
type() == item->type()
as literals of different types had different type().
After MDEV-14630 type() for literals of all data types return CONST_ITEM.
This caused failures in tests:
./mtr engines/iuds.insert_number
./mtr --ps --embedded main.explain_slowquerylog
(revealed by buildbot)
The essence of the fix:
Making literals and Item_param reuse the same code to avoid
asymmetries between Item_param::eq(Item_literal) and
Item_literal::eq(Item_param), now and in the future, and to
avoid code duplication between Item_literal and Item_param.
Adding tests for "decimals" for DECIMAL and temporal data types,
to treat constants of different scale as not equal when "binary_cmp"
is "true".
Details:
1. Adding a helper class Item_const to extract constant values from Items easier
2. Deriving Item_basic_value from Item_const
3. Joining Type_handler::Item_basic_value_eq() and Item_basic_value_bin_eq()
into a single method with an extra "binary_cmp" argument
(it looks simple this way) and renaming the new method to Item_const_eq().
Modifying its implementations to operate with
Item_const instead of Item_basic_value.
4. Adding a new class Type_handler_hex_hybrid,
to handle hex constants like 0x616263.
5. Removing Item::VARBIN_ITEM and fixing Item_hex_constant to
use type_handler_hex_hybrid instead of type_handler_varchar.
Item_hex_hybrid::type() now returns CONST_ITEM, like all
other literals do.
6. Move virtual methods Item::type_handler_for_system_time() and
Item::cast_to_int_type_handler() from Item to Type_handler.
7. Removing Item_decimal::eq() and Item_temporal_literal::eq().
These classes are now handled by the generic Item_basic_value::eq().
8. Implementing Type_handler_temporal_result::Item_const_eq()
and Type_handler_decimal_result::Item_const_eq(),
this fixes MDEV-11361.
9. Adding tests for "decimals" into
Type_handler_decimal_result::Item_const_eq() and
Type_handler_temporal_result::Item_const_eq()
in case if "binary_cmp" is true.
This fixes MDEV-16426.
10. Moving Item_cache out of Item_basic_value.
They share nothing. It simplifies implementation
of Item_basic_value::eq(). Deriving Item_cache
directly from Item.
11. Adding class DbugStringItemTypeValue, which
used Item::print() internally, and using
in instead of the old debug printing code.
This gives nicer output in func_debug.result.
Changes N5 and N6 do not directly relate to the bugs fixed,
but make the code fully symmetric across all literal types.
Without a new handler Type_handler_hex_hybrid we'd have
to keep two code branches (for regular literals and for
hex hybrid literals).
2018-06-08 12:36:42 +04:00
EXECUTE IMMEDIATE 'SELECT * FROM t1 WHERE a BETWEEN TIME''00:00:00'' AND ?' USING TIME'00:00:00';
DROP TABLE t1;
CREATE TABLE t1 (a DATE);
INSERT INTO t1 VALUES ('2001-01-01'),('2001-01-02');
SELECT * FROM t1 WHERE a BETWEEN DATE'2001-01-01' AND DATE'2001-01-01';
EXECUTE IMMEDIATE 'SELECT * FROM t1 WHERE a BETWEEN DATE''2001-01-01'' AND ?' USING DATE'2001-01-01';
DROP TABLE t1;
CREATE TABLE t1 (a DATETIME);
INSERT INTO t1 VALUES ('2001-01-01 00:00:00'),('2001-01-01 00:00:00');
SELECT * FROM t1 WHERE a BETWEEN TIMESTAMP'2001-01-01 00:00:00' AND TIMESTAMP'2001-01-01 00:00:00';
EXECUTE IMMEDIATE 'SELECT * FROM t1 WHERE a BETWEEN TIMESTAMP''2001-01-01 00:00:00'' AND ?' USING TIMESTAMP'2001-01-01 00:00:00';
2018-06-05 22:26:24 +04:00
DROP TABLE t1;
MDEV-11361 Equal condition propagation does not work for DECIMAL and temporal dynamic SQL parameters
MDEV-16426 Optimizer erroneously treats equal constants of different formats as same
A cleanup for MDEV-14630: fixing a crash in Item_decimal::eq().
Problems:
- old implementations of Item_decimal::eq() and
Item_temporal_literal::eq() were not symmetric
with Item_param::eq(), this caused MDEV-11361.
- old implementations for DECIMAL and temporal data types
did not take into account that in case when eq() is called
with binary_cmp==true, {{eq()}} should check not only equality
of the two values, but also equality if their decimal precision.
This cuases MDEV-16426.
- Item_decimal::eq() crashes with "item" pointing
to a non-DECIMAL value. Before MDEV-14630
non-DECIMAL values were filtered out by the test:
type() == item->type()
as literals of different types had different type().
After MDEV-14630 type() for literals of all data types return CONST_ITEM.
This caused failures in tests:
./mtr engines/iuds.insert_number
./mtr --ps --embedded main.explain_slowquerylog
(revealed by buildbot)
The essence of the fix:
Making literals and Item_param reuse the same code to avoid
asymmetries between Item_param::eq(Item_literal) and
Item_literal::eq(Item_param), now and in the future, and to
avoid code duplication between Item_literal and Item_param.
Adding tests for "decimals" for DECIMAL and temporal data types,
to treat constants of different scale as not equal when "binary_cmp"
is "true".
Details:
1. Adding a helper class Item_const to extract constant values from Items easier
2. Deriving Item_basic_value from Item_const
3. Joining Type_handler::Item_basic_value_eq() and Item_basic_value_bin_eq()
into a single method with an extra "binary_cmp" argument
(it looks simple this way) and renaming the new method to Item_const_eq().
Modifying its implementations to operate with
Item_const instead of Item_basic_value.
4. Adding a new class Type_handler_hex_hybrid,
to handle hex constants like 0x616263.
5. Removing Item::VARBIN_ITEM and fixing Item_hex_constant to
use type_handler_hex_hybrid instead of type_handler_varchar.
Item_hex_hybrid::type() now returns CONST_ITEM, like all
other literals do.
6. Move virtual methods Item::type_handler_for_system_time() and
Item::cast_to_int_type_handler() from Item to Type_handler.
7. Removing Item_decimal::eq() and Item_temporal_literal::eq().
These classes are now handled by the generic Item_basic_value::eq().
8. Implementing Type_handler_temporal_result::Item_const_eq()
and Type_handler_decimal_result::Item_const_eq(),
this fixes MDEV-11361.
9. Adding tests for "decimals" into
Type_handler_decimal_result::Item_const_eq() and
Type_handler_temporal_result::Item_const_eq()
in case if "binary_cmp" is true.
This fixes MDEV-16426.
10. Moving Item_cache out of Item_basic_value.
They share nothing. It simplifies implementation
of Item_basic_value::eq(). Deriving Item_cache
directly from Item.
11. Adding class DbugStringItemTypeValue, which
used Item::print() internally, and using
in instead of the old debug printing code.
This gives nicer output in func_debug.result.
Changes N5 and N6 do not directly relate to the bugs fixed,
but make the code fully symmetric across all literal types.
Without a new handler Type_handler_hex_hybrid we'd have
to keep two code branches (for regular literals and for
hex hybrid literals).
2018-06-08 12:36:42 +04:00
SET SESSION debug_dbug="-d,Item_basic_value";
--echo #
--echo # MDEV-16426 Optimizer erroneously treats equal constants of different formats as same
--echo #
SET SESSION debug_dbug="+d,Item_basic_value";
2018-06-05 22:26:24 +04:00
CREATE TABLE t1 (a VARCHAR(10));
MDEV-11361 Equal condition propagation does not work for DECIMAL and temporal dynamic SQL parameters
MDEV-16426 Optimizer erroneously treats equal constants of different formats as same
A cleanup for MDEV-14630: fixing a crash in Item_decimal::eq().
Problems:
- old implementations of Item_decimal::eq() and
Item_temporal_literal::eq() were not symmetric
with Item_param::eq(), this caused MDEV-11361.
- old implementations for DECIMAL and temporal data types
did not take into account that in case when eq() is called
with binary_cmp==true, {{eq()}} should check not only equality
of the two values, but also equality if their decimal precision.
This cuases MDEV-16426.
- Item_decimal::eq() crashes with "item" pointing
to a non-DECIMAL value. Before MDEV-14630
non-DECIMAL values were filtered out by the test:
type() == item->type()
as literals of different types had different type().
After MDEV-14630 type() for literals of all data types return CONST_ITEM.
This caused failures in tests:
./mtr engines/iuds.insert_number
./mtr --ps --embedded main.explain_slowquerylog
(revealed by buildbot)
The essence of the fix:
Making literals and Item_param reuse the same code to avoid
asymmetries between Item_param::eq(Item_literal) and
Item_literal::eq(Item_param), now and in the future, and to
avoid code duplication between Item_literal and Item_param.
Adding tests for "decimals" for DECIMAL and temporal data types,
to treat constants of different scale as not equal when "binary_cmp"
is "true".
Details:
1. Adding a helper class Item_const to extract constant values from Items easier
2. Deriving Item_basic_value from Item_const
3. Joining Type_handler::Item_basic_value_eq() and Item_basic_value_bin_eq()
into a single method with an extra "binary_cmp" argument
(it looks simple this way) and renaming the new method to Item_const_eq().
Modifying its implementations to operate with
Item_const instead of Item_basic_value.
4. Adding a new class Type_handler_hex_hybrid,
to handle hex constants like 0x616263.
5. Removing Item::VARBIN_ITEM and fixing Item_hex_constant to
use type_handler_hex_hybrid instead of type_handler_varchar.
Item_hex_hybrid::type() now returns CONST_ITEM, like all
other literals do.
6. Move virtual methods Item::type_handler_for_system_time() and
Item::cast_to_int_type_handler() from Item to Type_handler.
7. Removing Item_decimal::eq() and Item_temporal_literal::eq().
These classes are now handled by the generic Item_basic_value::eq().
8. Implementing Type_handler_temporal_result::Item_const_eq()
and Type_handler_decimal_result::Item_const_eq(),
this fixes MDEV-11361.
9. Adding tests for "decimals" into
Type_handler_decimal_result::Item_const_eq() and
Type_handler_temporal_result::Item_const_eq()
in case if "binary_cmp" is true.
This fixes MDEV-16426.
10. Moving Item_cache out of Item_basic_value.
They share nothing. It simplifies implementation
of Item_basic_value::eq(). Deriving Item_cache
directly from Item.
11. Adding class DbugStringItemTypeValue, which
used Item::print() internally, and using
in instead of the old debug printing code.
This gives nicer output in func_debug.result.
Changes N5 and N6 do not directly relate to the bugs fixed,
but make the code fully symmetric across all literal types.
Without a new handler Type_handler_hex_hybrid we'd have
to keep two code branches (for regular literals and for
hex hybrid literals).
2018-06-08 12:36:42 +04:00
INSERT INTO t1 VALUES ('a'),('b'),('c');
SELECT * FROM t1 WHERE a BETWEEN 'a' AND 0x61;
EXECUTE IMMEDIATE 'SELECT * FROM t1 WHERE a BETWEEN ''a'' AND ?' USING 0x61;
2018-06-05 22:26:24 +04:00
DROP TABLE t1;
SET SESSION debug_dbug="-d,Item_basic_value";
MDEV-16454 Bad results for IN with ROW
Consider an IN predicate with ROW-type arguments:
predicant IN (value1, ..., valueM)
where predicant and all values consist of N elements.
When performing IN for these arguments, at every position i (1..N)
only data type of i-th element of predicant was taken into account,
while data types on i-th elements of value1..valueM were not taken.
These led to bad comparison data type detection, e.g. when
mixing unsigned and signed integer values.
After this change all element data types are taken into account.
So, for example, a mixture of unsigned and signed values is
now calculated using decimal and does not overflow any more.
Detailed changes:
1. All comparators for ROW elements are now created recursively
at fix_fields() time, inside cmp_item_row::prepare_comparators().
Previously prepare_comparators() installed comparators only
for temporal data types, while comparators for other types were
installed at execution time, in cmp_item_row::store_value().
2. Removing comparator creating code from cmp_item_row::store_value().
It was responsible for non-temporal data types.
3. Removing find_date_time_item(). It's not needed any more.
All ROW-element data types are now covered by
cmp_item_row::prepare_comparators().
4. Adding a helper method Item_args::alloc_and_extract_row_elements()
to extract elements from an array of ROW-type Items, from the given
position. Using this method to collect elements from the i-th
position and further pass them to
Type_handler_hybrid_field_type::aggregate_for_comparison().
5. Moving the call for alloc_comparators() inside
cmp_item_row::prepare_comparators(). This helps
to call prepare_comparators() for ROW elements recursively
(if elements appear to be ROWs again).
Moving alloc_comparators() from "public" to "private".
2018-06-27 16:07:21 +04:00
--echo #
--echo # MDEV-16454 Bad results for IN with ROW
--echo #
SET SESSION debug_dbug="+d,cmp_item";
SET SESSION debug_dbug="+d,Item_func_in";
SET SESSION debug_dbug="+d,Predicant_to_list_comparator";
SELECT (18446744073709551615,0) IN ((18446744073709551614,0),(-1,0));
SELECT (1,(0,0)) IN ((1,(1,0)),(0,(0,0)));
SELECT (1,(0,0),3) IN ((1,(1,0),3),(0,(0,0),3));
SELECT '0x' IN (0);
SELECT '0x' IN (0,1);
SELECT ('0x',1) IN ((0,1));
SELECT ('0x',1) IN ((0,1),(1,1));
SET SESSION debug_dbug="-d,Predicant_to_list_comparator";
SET SESSION debug_dbug="-d,Item_func_in";
SET SESSION debug_dbug="-d,cmp_item";
