mariadb/mysql-test/r/func_in.result

754 lines
25 KiB
Text
Raw Normal View History

drop table if exists t1, t2;
select 1 in (1,2,3);
1 in (1,2,3)
1
select 10 in (1,2,3);
10 in (1,2,3)
0
select NULL in (1,2,3);
NULL in (1,2,3)
NULL
select 1 in (1,NULL,3);
1 in (1,NULL,3)
1
select 3 in (1,NULL,3);
3 in (1,NULL,3)
1
select 10 in (1,NULL,3);
10 in (1,NULL,3)
NULL
select 1.5 in (1.5,2.5,3.5);
1.5 in (1.5,2.5,3.5)
1
select 10.5 in (1.5,2.5,3.5);
10.5 in (1.5,2.5,3.5)
0
select NULL in (1.5,2.5,3.5);
NULL in (1.5,2.5,3.5)
NULL
select 1.5 in (1.5,NULL,3.5);
1.5 in (1.5,NULL,3.5)
1
select 3.5 in (1.5,NULL,3.5);
3.5 in (1.5,NULL,3.5)
1
select 10.5 in (1.5,NULL,3.5);
10.5 in (1.5,NULL,3.5)
NULL
CREATE TABLE t1 (a int, b int, c int);
insert into t1 values (1,2,3), (1,NULL,3);
select 1 in (a,b,c) from t1;
1 in (a,b,c)
1
1
select 3 in (a,b,c) from t1;
3 in (a,b,c)
1
1
select 10 in (a,b,c) from t1;
10 in (a,b,c)
0
NULL
select NULL in (a,b,c) from t1;
NULL in (a,b,c)
NULL
NULL
drop table t1;
CREATE TABLE t1 (a float, b float, c float);
insert into t1 values (1.5,2.5,3.5), (1.5,NULL,3.5);
select 1.5 in (a,b,c) from t1;
1.5 in (a,b,c)
1
1
select 3.5 in (a,b,c) from t1;
3.5 in (a,b,c)
1
1
select 10.5 in (a,b,c) from t1;
10.5 in (a,b,c)
0
NULL
drop table t1;
CREATE TABLE t1 (a varchar(10), b varchar(10), c varchar(10));
insert into t1 values ('A','BC','EFD'), ('A',NULL,'EFD');
select 'A' in (a,b,c) from t1;
'A' in (a,b,c)
1
1
select 'EFD' in (a,b,c) from t1;
'EFD' in (a,b,c)
1
1
select 'XSFGGHF' in (a,b,c) from t1;
'XSFGGHF' in (a,b,c)
0
NULL
drop table t1;
CREATE TABLE t1 (field char(1));
INSERT INTO t1 VALUES ('A'),(NULL);
SELECT * from t1 WHERE field IN (NULL);
field
SELECT * from t1 WHERE field NOT IN (NULL);
field
SELECT * from t1 where field = field;
field
A
SELECT * from t1 where field <=> field;
field
A
NULL
DELETE FROM t1 WHERE field NOT IN (NULL);
SELECT * FROM t1;
field
A
NULL
drop table t1;
create table t1 (id int(10) primary key);
insert into t1 values (1),(2),(3),(4),(5),(6),(7),(8),(9);
select * from t1 where id in (2,5,9);
id
2
5
9
drop table t1;
create table t1 (
a char(1) character set latin1 collate latin1_general_ci,
b char(1) character set latin1 collate latin1_swedish_ci,
c char(1) character set latin1 collate latin1_danish_ci
);
insert into t1 values ('A','B','C');
insert into t1 values ('a','c','c');
select * from t1 where a in (b);
ERROR HY000: Illegal mix of collations (latin1_general_ci,IMPLICIT) and (latin1_swedish_ci,IMPLICIT) for operation '='
select * from t1 where a in (b,c);
ERROR HY000: Illegal mix of collations (latin1_general_ci,IMPLICIT), (latin1_swedish_ci,IMPLICIT), (latin1_danish_ci,IMPLICIT) for operation ' IN '
select * from t1 where 'a' in (a,b,c);
ERROR HY000: Illegal mix of collations for operation ' IN '
select * from t1 where 'a' in (a);
a b c
A B C
a c c
select * from t1 where a in ('a');
a b c
A B C
a c c
select * from t1 where 'a' collate latin1_general_ci in (a,b,c);
a b c
A B C
a c c
select * from t1 where 'a' collate latin1_bin in (a,b,c);
a b c
a c c
select * from t1 where 'a' in (a,b,c collate latin1_bin);
a b c
a c c
explain extended select * from t1 where 'a' in (a,b,c collate latin1_bin);
id select_type table type possible_keys key key_len ref rows filtered Extra
1 SIMPLE t1 ALL NULL NULL NULL NULL 2 100.00 Using where
Warnings:
Note 1003 select `test`.`t1`.`a` AS `a`,`test`.`t1`.`b` AS `b`,`test`.`t1`.`c` AS `c` from `test`.`t1` where ('a' in (`test`.`t1`.`a`,`test`.`t1`.`b`,(`test`.`t1`.`c` collate latin1_bin)))
drop table t1;
set names utf8;
create table t1 (a char(10) character set utf8 not null);
insert into t1 values ('bbbb'),(_koi8r'<27><><EFBFBD><EFBFBD>'),(_latin1'<27><><EFBFBD><EFBFBD>');
select a from t1 where a in ('bbbb',_koi8r'<27><><EFBFBD><EFBFBD>',_latin1'<27><><EFBFBD><EFBFBD>') order by a;
a
ÄÄÄÄ
bbbb
цццц
drop table t1;
create table t1 (a char(10) character set latin1 not null);
insert into t1 values ('a'),('b'),('c');
select a from t1 where a IN ('a','b','c') order by a;
a
a
b
c
drop table t1;
set names latin1;
select '1.0' in (1,2);
'1.0' in (1,2)
1
select 1 in ('1.0',2);
1 in ('1.0',2)
1
select 1 in (1,'2.0');
1 in (1,'2.0')
1
select 1 in ('1.0',2.0);
1 in ('1.0',2.0)
1
select 1 in (1.0,'2.0');
1 in (1.0,'2.0')
1
select 1 in ('1.1',2);
1 in ('1.1',2)
0
select 1 in ('1.1',2.0);
1 in ('1.1',2.0)
0
create table t1 (a char(2) character set binary);
insert into t1 values ('aa'), ('bb');
select * from t1 where a in (NULL, 'aa');
a
aa
drop table t1;
create table t1 (id int, key(id));
insert into t1 values (1),(2),(3);
select count(*) from t1 where id not in (1);
count(*)
2
select count(*) from t1 where id not in (1,2);
count(*)
1
drop table t1;
DROP TABLE IF EXISTS t1;
CREATE TABLE t1 SELECT 1 IN (2, NULL);
SELECT should return NULL.
SELECT * FROM t1;
1 IN (2, NULL)
NULL
DROP TABLE t1;
End of 4.1 tests
CREATE TABLE t1 (a int PRIMARY KEY);
INSERT INTO t1 VALUES (44), (45), (46);
SELECT * FROM t1 WHERE a IN (45);
a
45
SELECT * FROM t1 WHERE a NOT IN (0, 45);
a
44
46
SELECT * FROM t1 WHERE a NOT IN (45);
a
44
46
CREATE VIEW v1 AS SELECT * FROM t1 WHERE a NOT IN (45);
SHOW CREATE VIEW v1;
Patch for the following bugs: - BUG#11986: Stored routines and triggers can fail if the code has a non-ascii symbol - BUG#16291: mysqldump corrupts string-constants with non-ascii-chars - BUG#19443: INFORMATION_SCHEMA does not support charsets properly - BUG#21249: Character set of SP-var can be ignored - BUG#25212: Character set of string constant is ignored (stored routines) - BUG#25221: Character set of string constant is ignored (triggers) There were a few general problems that caused these bugs: 1. Character set information of the original (definition) query for views, triggers, stored routines and events was lost. 2. mysqldump output query in client character set, which can be inappropriate to encode definition-query. 3. INFORMATION_SCHEMA used strings with mixed encodings to display object definition; 1. No query-definition-character set. In order to compile query into execution code, some extra data (such as environment variables or the database character set) is used. The problem here was that this context was not preserved. So, on the next load it can differ from the original one, thus the result will be different. The context contains the following data: - client character set; - connection collation (character set and collation); - collation of the owner database; The fix is to store this context and use it each time we parse (compile) and execute the object (stored routine, trigger, ...). 2. Wrong mysqldump-output. The original query can contain several encodings (by means of character set introducers). The problem here was that we tried to convert original query to the mysqldump-client character set. Moreover, we stored queries in different character sets for different objects (views, for one, used UTF8, triggers used original character set). The solution is - to store definition queries in the original character set; - to change SHOW CREATE statement to output definition query in the binary character set (i.e. without any conversion); - introduce SHOW CREATE TRIGGER statement; - to dump special statements to switch the context to the original one before dumping and restore it afterwards. Note, in order to preserve the database collation at the creation time, additional ALTER DATABASE might be used (to temporary switch the database collation back to the original value). In this case, ALTER DATABASE privilege will be required. This is a backward-incompatible change. 3. INFORMATION_SCHEMA showed non-UTF8 strings The fix is to generate UTF8-query during the parsing, store it in the object and show it in the INFORMATION_SCHEMA. Basically, the idea is to create a copy of the original query convert it to UTF8. Character set introducers are removed and all text literals are converted to UTF8. This UTF8 query is intended to provide user-readable output. It must not be used to recreate the object. Specialized SHOW CREATE statements should be used for this. The reason for this limitation is the following: the original query can contain symbols from several character sets (by means of character set introducers). Example: - original query: CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1; - UTF8 query (for INFORMATION_SCHEMA): CREATE VIEW v1 AS SELECT 'Hello' AS c1;
2007-06-28 19:34:54 +02:00
View Create View character_set_client collation_connection
v1 CREATE ALGORITHM=UNDEFINED DEFINER=`root`@`localhost` SQL SECURITY DEFINER VIEW `v1` AS select `t1`.`a` AS `a` from `t1` where (`t1`.`a` <> 45) latin1 latin1_swedish_ci
SELECT * FROM v1;
a
44
46
DROP VIEW v1;
DROP TABLE t1;
create table t1 (a int);
insert into t1 values (0),(1),(2),(3),(4),(5),(6),(7),(8),(9);
create table t2 (a int, filler char(200), key(a));
insert into t2 select C.a*2, 'no' from t1 A, t1 B, t1 C;
insert into t2 select C.a*2+1, 'yes' from t1 C;
explain
select * from t2 where a NOT IN (0, 2,4,6,8,10,12,14,16,18);
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t2 range a a 5 NULL 12 Using where
select * from t2 where a NOT IN (0, 2,4,6,8,10,12,14,16,18);
a filler
1 yes
3 yes
5 yes
7 yes
9 yes
11 yes
13 yes
15 yes
17 yes
19 yes
explain select * from t2 force index(a) where a NOT IN (2,2,2,2,2,2);
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t2 range a a 5 NULL 912 Using where
explain select * from t2 force index(a) where a <> 2;
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t2 range a a 5 NULL 912 Using where
drop table t2;
create table t2 (a datetime, filler char(200), key(a));
insert into t2 select '2006-04-25 10:00:00' + interval C.a minute,
'no' from t1 A, t1 B, t1 C where C.a % 2 = 0;
insert into t2 select '2006-04-25 10:00:00' + interval C.a*2+1 minute,
'yes' from t1 C;
explain
select * from t2 where a NOT IN (
'2006-04-25 10:00:00','2006-04-25 10:02:00','2006-04-25 10:04:00',
'2006-04-25 10:06:00', '2006-04-25 10:08:00');
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t2 range a a 9 NULL 18 Using where
select * from t2 where a NOT IN (
'2006-04-25 10:00:00','2006-04-25 10:02:00','2006-04-25 10:04:00',
'2006-04-25 10:06:00', '2006-04-25 10:08:00');
a filler
2006-04-25 10:01:00 yes
2006-04-25 10:03:00 yes
2006-04-25 10:05:00 yes
2006-04-25 10:07:00 yes
2006-04-25 10:09:00 yes
2006-04-25 10:11:00 yes
2006-04-25 10:13:00 yes
2006-04-25 10:15:00 yes
2006-04-25 10:17:00 yes
2006-04-25 10:19:00 yes
drop table t2;
create table t2 (a varchar(10), filler char(200), key(a));
insert into t2 select 'foo', 'no' from t1 A, t1 B;
insert into t2 select 'barbar', 'no' from t1 A, t1 B;
insert into t2 select 'bazbazbaz', 'no' from t1 A, t1 B;
insert into t2 values ('fon', '1'), ('fop','1'), ('barbaq','1'),
('barbas','1'), ('bazbazbay', '1'),('zz','1');
explain select * from t2 where a not in('foo','barbar', 'bazbazbaz');
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t2 range a a 13 NULL 7 Using where
drop table t2;
create table t2 (a decimal(10,5), filler char(200), key(a));
insert into t2 select 345.67890, 'no' from t1 A, t1 B;
insert into t2 select 43245.34, 'no' from t1 A, t1 B;
insert into t2 select 64224.56344, 'no' from t1 A, t1 B;
insert into t2 values (0, '1'), (22334.123,'1'), (33333,'1'),
(55555,'1'), (77777, '1');
explain
select * from t2 where a not in (345.67890, 43245.34, 64224.56344);
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t2 range a a 7 NULL 7 Using where
select * from t2 where a not in (345.67890, 43245.34, 64224.56344);
a filler
0.00000 1
22334.12300 1
33333.00000 1
55555.00000 1
77777.00000 1
drop table t2;
create table t2 (a int, key(a), b int);
insert into t2 values (1,1),(2,2);
set @cnt= 1;
set @str="update t2 set b=1 where a not in (";
select count(*) from (
select @str:=concat(@str, @cnt:=@cnt+1, ",")
from t1 A, t1 B, t1 C, t1 D) Z;
count(*)
10000
set @str:=concat(@str, "10000)");
select substr(@str, 1, 50);
substr(@str, 1, 50)
update t2 set b=1 where a not in (2,3,4,5,6,7,8,9,
prepare s from @str;
execute s;
deallocate prepare s;
set @str=NULL;
drop table t2;
drop table t1;
create table t1 (
some_id smallint(5) unsigned,
key (some_id)
);
insert into t1 values (1),(2);
select some_id from t1 where some_id not in(2,-1);
some_id
1
select some_id from t1 where some_id not in(-4,-1,-4);
some_id
1
2
select some_id from t1 where some_id not in(-4,-1,3423534,2342342);
some_id
1
2
select some_id from t1 where some_id not in('-1', '0');
some_id
1
2
drop table t1;
CREATE TABLE t1 (a int, b int, PRIMARY KEY (a));
INSERT INTO t1 VALUES (1,1),(2,1),(3,1),(4,1),(5,1),(6,1);
CREATE TABLE t2 (a int, b int, PRIMARY KEY (a));
INSERT INTO t2 VALUES (3,2),(4,2),(100,100),(101,201),(102,102);
CREATE TABLE t3 (a int PRIMARY KEY);
INSERT INTO t3 VALUES (1),(2),(3),(4);
CREATE TABLE t4 (a int PRIMARY KEY,b int);
INSERT INTO t4 VALUES (1,1),(2,2),(1000,1000),(1001,1001),(1002,1002),
(1003,1003),(1004,1004);
EXPLAIN SELECT STRAIGHT_JOIN * FROM t3
JOIN t1 ON t3.a=t1.a
JOIN t2 ON t3.a=t2.a
JOIN t4 WHERE t4.a IN (t1.b, t2.b);
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t3 index PRIMARY PRIMARY 4 NULL 4 Using index
1 SIMPLE t1 eq_ref PRIMARY PRIMARY 4 test.t3.a 1
1 SIMPLE t2 eq_ref PRIMARY PRIMARY 4 test.t3.a 1
1 SIMPLE t4 ALL PRIMARY NULL NULL NULL 7 Range checked for each record (index map: 0x1)
SELECT STRAIGHT_JOIN * FROM t3
JOIN t1 ON t3.a=t1.a
JOIN t2 ON t3.a=t2.a
JOIN t4 WHERE t4.a IN (t1.b, t2.b);
a a b a b a b
3 3 1 3 2 1 1
3 3 1 3 2 2 2
4 4 1 4 2 1 1
4 4 1 4 2 2 2
EXPLAIN SELECT STRAIGHT_JOIN
(SELECT SUM(t4.a) FROM t4 WHERE t4.a IN (t1.b, t2.b))
FROM t3, t1, t2
WHERE t3.a=t1.a AND t3.a=t2.a;
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY t3 index PRIMARY PRIMARY 4 NULL 4 Using index
1 PRIMARY t1 eq_ref PRIMARY PRIMARY 4 test.t3.a 1
1 PRIMARY t2 eq_ref PRIMARY PRIMARY 4 test.t3.a 1
2 DEPENDENT SUBQUERY t4 index NULL PRIMARY 4 NULL 7 Using where; Using index
SELECT STRAIGHT_JOIN
(SELECT SUM(t4.a) FROM t4 WHERE t4.a IN (t1.b, t2.b))
FROM t3, t1, t2
WHERE t3.a=t1.a AND t3.a=t2.a;
(SELECT SUM(t4.a) FROM t4 WHERE t4.a IN (t1.b, t2.b))
3
3
DROP TABLE t1,t2,t3,t4;
CREATE TABLE t1(a BIGINT UNSIGNED);
INSERT INTO t1 VALUES (0xFFFFFFFFFFFFFFFF);
SELECT * FROM t1 WHERE a=-1 OR a=-2 ;
a
SELECT * FROM t1 WHERE a IN (-1, -2);
a
CREATE TABLE t2 (a BIGINT UNSIGNED);
insert into t2 values(13491727406643098568),
(0x7fffffefffffffff),
(0x7ffffffeffffffff),
(0x7fffffffefffffff),
(0x7ffffffffeffffff),
(0x7fffffffffefffff),
(0x7ffffffffffeffff),
(0x7fffffffffffefff),
(0x7ffffffffffffeff),
(0x7fffffffffffffef),
(0x7ffffffffffffffe),
(0x7fffffffffffffff),
(0x8000000000000000),
(0x8000000000000001),
(0x8000000000000002),
(0x8000000000000300),
(0x8000000000000400),
(0x8000000000000401),
(0x8000000000004001),
(0x8000000000040001),
(0x8000000000400001),
(0x8000000004000001),
(0x8000000040000001),
(0x8000000400000001),
(0x8000004000000001),
(0x8000040000000001);
SELECT HEX(a) FROM t2 WHERE a IN
(CAST(0xBB3C3E98175D33C8 AS UNSIGNED),
42);
HEX(a)
BB3C3E98175D33C8
SELECT HEX(a) FROM t2 WHERE a IN
(CAST(0xBB3C3E98175D33C8 AS UNSIGNED),
CAST(0x7fffffffffffffff AS UNSIGNED),
CAST(0x8000000000000000 AS UNSIGNED),
CAST(0x8000000000000400 AS UNSIGNED),
CAST(0x8000000000000401 AS UNSIGNED),
42);
HEX(a)
BB3C3E98175D33C8
7FFFFFFFFFFFFFFF
8000000000000000
8000000000000400
8000000000000401
SELECT HEX(a) FROM t2 WHERE a IN
(CAST(0x7fffffffffffffff AS UNSIGNED),
CAST(0x8000000000000001 AS UNSIGNED));
HEX(a)
7FFFFFFFFFFFFFFF
8000000000000001
SELECT HEX(a) FROM t2 WHERE a IN
(CAST(0x7ffffffffffffffe AS UNSIGNED),
CAST(0x7fffffffffffffff AS UNSIGNED));
HEX(a)
7FFFFFFFFFFFFFFE
7FFFFFFFFFFFFFFF
SELECT HEX(a) FROM t2 WHERE a IN
(0x7ffffffffffffffe,
0x7fffffffffffffff,
'abc');
HEX(a)
7FFFFFFFFFFFFFFE
7FFFFFFFFFFFFFFF
CREATE TABLE t3 (a BIGINT UNSIGNED);
INSERT INTO t3 VALUES (9223372036854775551);
SELECT HEX(a) FROM t3 WHERE a IN (9223372036854775807, 42);
HEX(a)
CREATE TABLE t4 (a DATE);
INSERT INTO t4 VALUES ('1972-02-06'), ('1972-07-29');
SELECT * FROM t4 WHERE a IN ('1972-02-06','19772-07-29');
a
1972-02-06
Warnings:
Warning 1292 Incorrect date value: '19772-07-29' for column 'a' at row 1
DROP TABLE t1,t2,t3,t4;
CREATE TABLE t1 (id int not null);
INSERT INTO t1 VALUES (1),(2);
SELECT id FROM t1 WHERE id IN(4564, (SELECT IF(1=0,1,1/0)) );
id
DROP TABLE t1;
End of 5.0 tests
Fixed bug #18360: Type aggregation for IN and CASE may lead to a wrong result The IN function aggregates result types of all expressions. It uses that type in comparison of left expression and expressions in right part. This approach works in most cases. But let's consider the case when the right part contains both strings and integers. In that case this approach may cause wrong results because all strings which do not start with a digit are evaluated as 0. CASE uses the same approach when a CASE expression is given thus it's also affected. The idea behind this fix is to make IN function to compare expressions with different result types differently. For example a string in the left part will be compared as string with strings specified in right part and will be converted to real for comparison to int or real items in the right part. A new function called collect_cmp_types() is added. It collects different result types for comparison of first item in the provided list with each other item in the list. The Item_func_in class now can refer up to 5 cmp_item objects: 1 for each result type for comparison purposes. cmp_item objects are allocated according to found result types. The comparison of the left expression with any right part expression is now based only on result types of these expressions. The Item_func_case class is modified in the similar way when a CASE expression is specified. Now it can allocate up to 5 cmp_item objects to compare CASE expression with WHEN expressions of different types. The comparison of the CASE expression with any WHEN expression now based only on result types of these expressions.
2006-09-26 18:52:54 +02:00
create table t1(f1 char(1));
insert into t1 values ('a'),('b'),('1');
select f1 from t1 where f1 in ('a',1);
f1
a
1
Warnings:
Warning 1292 Truncated incorrect DOUBLE value: 'b'
Fixed bug #18360: Type aggregation for IN and CASE may lead to a wrong result The IN function aggregates result types of all expressions. It uses that type in comparison of left expression and expressions in right part. This approach works in most cases. But let's consider the case when the right part contains both strings and integers. In that case this approach may cause wrong results because all strings which do not start with a digit are evaluated as 0. CASE uses the same approach when a CASE expression is given thus it's also affected. The idea behind this fix is to make IN function to compare expressions with different result types differently. For example a string in the left part will be compared as string with strings specified in right part and will be converted to real for comparison to int or real items in the right part. A new function called collect_cmp_types() is added. It collects different result types for comparison of first item in the provided list with each other item in the list. The Item_func_in class now can refer up to 5 cmp_item objects: 1 for each result type for comparison purposes. cmp_item objects are allocated according to found result types. The comparison of the left expression with any right part expression is now based only on result types of these expressions. The Item_func_case class is modified in the similar way when a CASE expression is specified. Now it can allocate up to 5 cmp_item objects to compare CASE expression with WHEN expressions of different types. The comparison of the CASE expression with any WHEN expression now based only on result types of these expressions.
2006-09-26 18:52:54 +02:00
select f1, case f1 when 'a' then '+' when 1 then '-' end from t1;
f1 case f1 when 'a' then '+' when 1 then '-' end
a +
b NULL
1 -
Warnings:
Warning 1292 Truncated incorrect DOUBLE value: 'b'
Fixed bug #18360: Type aggregation for IN and CASE may lead to a wrong result The IN function aggregates result types of all expressions. It uses that type in comparison of left expression and expressions in right part. This approach works in most cases. But let's consider the case when the right part contains both strings and integers. In that case this approach may cause wrong results because all strings which do not start with a digit are evaluated as 0. CASE uses the same approach when a CASE expression is given thus it's also affected. The idea behind this fix is to make IN function to compare expressions with different result types differently. For example a string in the left part will be compared as string with strings specified in right part and will be converted to real for comparison to int or real items in the right part. A new function called collect_cmp_types() is added. It collects different result types for comparison of first item in the provided list with each other item in the list. The Item_func_in class now can refer up to 5 cmp_item objects: 1 for each result type for comparison purposes. cmp_item objects are allocated according to found result types. The comparison of the left expression with any right part expression is now based only on result types of these expressions. The Item_func_case class is modified in the similar way when a CASE expression is specified. Now it can allocate up to 5 cmp_item objects to compare CASE expression with WHEN expressions of different types. The comparison of the CASE expression with any WHEN expression now based only on result types of these expressions.
2006-09-26 18:52:54 +02:00
create index t1f1_idx on t1(f1);
select f1 from t1 where f1 in ('a',1);
f1
1
a
Warnings:
Warning 1292 Truncated incorrect DOUBLE value: 'b'
Fixed bug #18360: Type aggregation for IN and CASE may lead to a wrong result The IN function aggregates result types of all expressions. It uses that type in comparison of left expression and expressions in right part. This approach works in most cases. But let's consider the case when the right part contains both strings and integers. In that case this approach may cause wrong results because all strings which do not start with a digit are evaluated as 0. CASE uses the same approach when a CASE expression is given thus it's also affected. The idea behind this fix is to make IN function to compare expressions with different result types differently. For example a string in the left part will be compared as string with strings specified in right part and will be converted to real for comparison to int or real items in the right part. A new function called collect_cmp_types() is added. It collects different result types for comparison of first item in the provided list with each other item in the list. The Item_func_in class now can refer up to 5 cmp_item objects: 1 for each result type for comparison purposes. cmp_item objects are allocated according to found result types. The comparison of the left expression with any right part expression is now based only on result types of these expressions. The Item_func_case class is modified in the similar way when a CASE expression is specified. Now it can allocate up to 5 cmp_item objects to compare CASE expression with WHEN expressions of different types. The comparison of the CASE expression with any WHEN expression now based only on result types of these expressions.
2006-09-26 18:52:54 +02:00
explain select f1 from t1 where f1 in ('a',1);
id select_type table type possible_keys key key_len ref rows Extra
2007-01-24 14:55:16 +01:00
1 SIMPLE t1 index t1f1_idx t1f1_idx 2 NULL 3 Using where; Using index
Fixed bug #18360: Type aggregation for IN and CASE may lead to a wrong result The IN function aggregates result types of all expressions. It uses that type in comparison of left expression and expressions in right part. This approach works in most cases. But let's consider the case when the right part contains both strings and integers. In that case this approach may cause wrong results because all strings which do not start with a digit are evaluated as 0. CASE uses the same approach when a CASE expression is given thus it's also affected. The idea behind this fix is to make IN function to compare expressions with different result types differently. For example a string in the left part will be compared as string with strings specified in right part and will be converted to real for comparison to int or real items in the right part. A new function called collect_cmp_types() is added. It collects different result types for comparison of first item in the provided list with each other item in the list. The Item_func_in class now can refer up to 5 cmp_item objects: 1 for each result type for comparison purposes. cmp_item objects are allocated according to found result types. The comparison of the left expression with any right part expression is now based only on result types of these expressions. The Item_func_case class is modified in the similar way when a CASE expression is specified. Now it can allocate up to 5 cmp_item objects to compare CASE expression with WHEN expressions of different types. The comparison of the CASE expression with any WHEN expression now based only on result types of these expressions.
2006-09-26 18:52:54 +02:00
select f1 from t1 where f1 in ('a','b');
f1
a
b
explain select f1 from t1 where f1 in ('a','b');
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 index t1f1_idx t1f1_idx 2 NULL 3 Using where; Using index
select f1 from t1 where f1 in (2,1);
f1
1
Warnings:
Warning 1292 Truncated incorrect DOUBLE value: 'a'
Warning 1292 Truncated incorrect DOUBLE value: 'b'
Fixed bug #18360: Type aggregation for IN and CASE may lead to a wrong result The IN function aggregates result types of all expressions. It uses that type in comparison of left expression and expressions in right part. This approach works in most cases. But let's consider the case when the right part contains both strings and integers. In that case this approach may cause wrong results because all strings which do not start with a digit are evaluated as 0. CASE uses the same approach when a CASE expression is given thus it's also affected. The idea behind this fix is to make IN function to compare expressions with different result types differently. For example a string in the left part will be compared as string with strings specified in right part and will be converted to real for comparison to int or real items in the right part. A new function called collect_cmp_types() is added. It collects different result types for comparison of first item in the provided list with each other item in the list. The Item_func_in class now can refer up to 5 cmp_item objects: 1 for each result type for comparison purposes. cmp_item objects are allocated according to found result types. The comparison of the left expression with any right part expression is now based only on result types of these expressions. The Item_func_case class is modified in the similar way when a CASE expression is specified. Now it can allocate up to 5 cmp_item objects to compare CASE expression with WHEN expressions of different types. The comparison of the CASE expression with any WHEN expression now based only on result types of these expressions.
2006-09-26 18:52:54 +02:00
explain select f1 from t1 where f1 in (2,1);
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 index t1f1_idx t1f1_idx 2 NULL 3 Using where; Using index
create table t2(f2 int, index t2f2(f2));
insert into t2 values(0),(1),(2);
select f2 from t2 where f2 in ('a',2);
f2
0
2
Warnings:
Warning 1292 Truncated incorrect DOUBLE value: 'a'
Warning 1292 Truncated incorrect DOUBLE value: 'a'
Warning 1292 Truncated incorrect DOUBLE value: 'a'
explain select f2 from t2 where f2 in ('a',2);
id select_type table type possible_keys key key_len ref rows Extra
2007-01-24 14:55:16 +01:00
1 SIMPLE t2 index t2f2 t2f2 5 NULL 3 Using where; Using index
Fixed bug #18360: Type aggregation for IN and CASE may lead to a wrong result The IN function aggregates result types of all expressions. It uses that type in comparison of left expression and expressions in right part. This approach works in most cases. But let's consider the case when the right part contains both strings and integers. In that case this approach may cause wrong results because all strings which do not start with a digit are evaluated as 0. CASE uses the same approach when a CASE expression is given thus it's also affected. The idea behind this fix is to make IN function to compare expressions with different result types differently. For example a string in the left part will be compared as string with strings specified in right part and will be converted to real for comparison to int or real items in the right part. A new function called collect_cmp_types() is added. It collects different result types for comparison of first item in the provided list with each other item in the list. The Item_func_in class now can refer up to 5 cmp_item objects: 1 for each result type for comparison purposes. cmp_item objects are allocated according to found result types. The comparison of the left expression with any right part expression is now based only on result types of these expressions. The Item_func_case class is modified in the similar way when a CASE expression is specified. Now it can allocate up to 5 cmp_item objects to compare CASE expression with WHEN expressions of different types. The comparison of the CASE expression with any WHEN expression now based only on result types of these expressions.
2006-09-26 18:52:54 +02:00
select f2 from t2 where f2 in ('a','b');
f2
0
Warnings:
Warning 1292 Truncated incorrect DOUBLE value: 'a'
Warning 1292 Truncated incorrect DOUBLE value: 'b'
explain select f2 from t2 where f2 in ('a','b');
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t2 index t2f2 t2f2 5 NULL 3 Using where; Using index
Warnings:
Warning 1292 Truncated incorrect DOUBLE value: 'a'
Warning 1292 Truncated incorrect DOUBLE value: 'b'
select f2 from t2 where f2 in (1,'b');
f2
0
1
Warnings:
Warning 1292 Truncated incorrect DOUBLE value: 'b'
Warning 1292 Truncated incorrect DOUBLE value: 'b'
explain select f2 from t2 where f2 in (1,'b');
id select_type table type possible_keys key key_len ref rows Extra
2007-01-24 14:55:16 +01:00
1 SIMPLE t2 index t2f2 t2f2 5 NULL 3 Using where; Using index
Fixed bug #18360: Type aggregation for IN and CASE may lead to a wrong result The IN function aggregates result types of all expressions. It uses that type in comparison of left expression and expressions in right part. This approach works in most cases. But let's consider the case when the right part contains both strings and integers. In that case this approach may cause wrong results because all strings which do not start with a digit are evaluated as 0. CASE uses the same approach when a CASE expression is given thus it's also affected. The idea behind this fix is to make IN function to compare expressions with different result types differently. For example a string in the left part will be compared as string with strings specified in right part and will be converted to real for comparison to int or real items in the right part. A new function called collect_cmp_types() is added. It collects different result types for comparison of first item in the provided list with each other item in the list. The Item_func_in class now can refer up to 5 cmp_item objects: 1 for each result type for comparison purposes. cmp_item objects are allocated according to found result types. The comparison of the left expression with any right part expression is now based only on result types of these expressions. The Item_func_case class is modified in the similar way when a CASE expression is specified. Now it can allocate up to 5 cmp_item objects to compare CASE expression with WHEN expressions of different types. The comparison of the CASE expression with any WHEN expression now based only on result types of these expressions.
2006-09-26 18:52:54 +02:00
drop table t1, t2;
create table t1 (a time, key(a));
insert into t1 values (),(),(),(),(),(),(),(),(),();
select a from t1 where a not in (a,a,a) group by a;
a
drop table t1;
create table t1 (id int);
select * from t1 where NOT id in (select null union all select 1);
id
select * from t1 where NOT id in (null, 1);
id
drop table t1;
CREATE TABLE t1(c0 INTEGER, c1 INTEGER, c2 INTEGER);
INSERT INTO t1 VALUES(1, 1, 1), (1, 1, 1);
SELECT CASE AVG (c0) WHEN c1 * c2 THEN 1 END FROM t1;
CASE AVG (c0) WHEN c1 * c2 THEN 1 END
1
SELECT CASE c1 * c2 WHEN SUM(c0) THEN 1 WHEN AVG(c0) THEN 2 END FROM t1;
CASE c1 * c2 WHEN SUM(c0) THEN 1 WHEN AVG(c0) THEN 2 END
2
SELECT CASE c1 WHEN c1 + 1 THEN 1 END, ABS(AVG(c0)) FROM t1;
CASE c1 WHEN c1 + 1 THEN 1 END ABS(AVG(c0))
NULL 1.0000
DROP TABLE t1;
CREATE TABLE t1(a TEXT, b INT, c INT UNSIGNED, d DECIMAL(12,2), e REAL);
INSERT INTO t1 VALUES('iynfj', 1, 1, 1, 1);
INSERT INTO t1 VALUES('innfj', 2, 2, 2, 2);
SELECT SUM( DISTINCT a ) FROM t1 GROUP BY a HAVING a IN ( AVG( 1 ), 1 + a);
SUM( DISTINCT a )
SELECT SUM( DISTINCT b ) FROM t1 GROUP BY b HAVING b IN ( AVG( 1 ), 1 + b);
SUM( DISTINCT b )
1
SELECT SUM( DISTINCT c ) FROM t1 GROUP BY c HAVING c IN ( AVG( 1 ), 1 + c);
SUM( DISTINCT c )
1
SELECT SUM( DISTINCT d ) FROM t1 GROUP BY d HAVING d IN ( AVG( 1 ), 1 + d);
SUM( DISTINCT d )
1.00
SELECT SUM( DISTINCT e ) FROM t1 GROUP BY e HAVING e IN ( AVG( 1 ), 1 + e);
SUM( DISTINCT e )
1
SELECT SUM( DISTINCT e ) FROM t1 GROUP BY b,c,d HAVING (b,c,d) IN
((AVG( 1 ), 1 + c, 1 + d), (AVG( 1 ), 2 + c, 2 + d));
SUM( DISTINCT e )
DROP TABLE t1;
Bug #44139: Table scan when NULL appears in IN clause SELECT ... WHERE ... IN (NULL, ...) does full table scan, even if the same query without the NULL uses efficient range scan. The bugfix for the bug 18360 introduced an optimization: if 1) all right-hand arguments of the IN function are constants 2) result types of all right argument items are compatible enough to use the same single comparison function to compare all of them to the left argument, then we can convert the right-hand list of constant items to an array of equally-typed constant values for the further QUICK index access etc. (see Item_func_in::fix_length_and_dec()). The Item_null constant item objects have STRING_RESULT result types, so, as far as Item_func_in::fix_length_and_dec() is aware of NULLs in the right list, this improvement efficiently optimizes IN function calls with a mixed right list of NULLs and string constants. However, the optimization doesn't affect mixed lists of NULLs and integers, floats etc., because there is no unique common comparator. New optimization has been added to ignore the result type of NULL constants in the static analysis of mixed right-hand lists. This is safe, because at the execution phase we care about presence of NULLs anyway. 1. The collect_cmp_types() function has been modified to optionally ignore NULL constants in the item list. 2. NULL-skipping code of the Item_func_in::fix_length_and_dec() function has been modified to work not only with in_string vectors but with in_vectors of other types.
2009-10-05 07:27:36 +02:00
#
# Bug #44139: Table scan when NULL appears in IN clause
#
CREATE TABLE t1 (
c_int INT NOT NULL,
c_decimal DECIMAL(5,2) NOT NULL,
c_float FLOAT(5, 2) NOT NULL,
c_bit BIT(10) NOT NULL,
c_date DATE NOT NULL,
c_datetime DATETIME NOT NULL,
c_timestamp TIMESTAMP NOT NULL,
c_time TIME NOT NULL,
c_year YEAR NOT NULL,
c_char CHAR(10) NOT NULL,
INDEX(c_int), INDEX(c_decimal), INDEX(c_float), INDEX(c_bit), INDEX(c_date),
INDEX(c_datetime), INDEX(c_timestamp), INDEX(c_time), INDEX(c_year),
INDEX(c_char));
INSERT INTO t1 (c_int) VALUES (1), (2), (3), (4), (5);
INSERT INTO t1 (c_int) SELECT 0 FROM t1;
INSERT INTO t1 (c_int) SELECT 0 FROM t1;
EXPLAIN SELECT * FROM t1 WHERE c_int IN (1, 2, 3);
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 range c_int c_int 4 NULL 3 Using where
EXPLAIN SELECT * FROM t1 WHERE c_int IN (NULL, 1, 2, 3);
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 range c_int c_int 4 NULL 3 Using where
EXPLAIN SELECT * FROM t1 WHERE c_int IN (1, 2, 3);
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 range c_int c_int 4 NULL 3 Using where
EXPLAIN SELECT * FROM t1 WHERE c_int IN (1, NULL, 2, NULL, 3, NULL);
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 range c_int c_int 4 NULL 3 Using where
EXPLAIN SELECT * FROM t1 WHERE c_int IN (NULL);
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE NULL NULL NULL NULL NULL NULL NULL Impossible WHERE noticed after reading const tables
EXPLAIN SELECT * FROM t1 WHERE c_int IN (NULL, NULL);
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE NULL NULL NULL NULL NULL NULL NULL Impossible WHERE noticed after reading const tables
EXPLAIN SELECT * FROM t1 WHERE c_decimal IN (1, 2, 3);
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 range c_decimal c_decimal 3 NULL 3 Using where
EXPLAIN SELECT * FROM t1 WHERE c_decimal IN (NULL, 1, 2, 3);
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 range c_decimal c_decimal 3 NULL 3 Using where
EXPLAIN SELECT * FROM t1 WHERE c_decimal IN (NULL);
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE NULL NULL NULL NULL NULL NULL NULL Impossible WHERE noticed after reading const tables
EXPLAIN SELECT * FROM t1 WHERE c_decimal IN (NULL, NULL);
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE NULL NULL NULL NULL NULL NULL NULL Impossible WHERE noticed after reading const tables
EXPLAIN SELECT * FROM t1 WHERE c_float IN (1, 2, 3);
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 range c_float c_float 4 NULL 3 Using where
EXPLAIN SELECT * FROM t1 WHERE c_float IN (NULL, 1, 2, 3);
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 range c_float c_float 4 NULL 3 Using where
EXPLAIN SELECT * FROM t1 WHERE c_float IN (NULL);
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE NULL NULL NULL NULL NULL NULL NULL Impossible WHERE noticed after reading const tables
EXPLAIN SELECT * FROM t1 WHERE c_float IN (NULL, NULL);
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE NULL NULL NULL NULL NULL NULL NULL Impossible WHERE noticed after reading const tables
EXPLAIN SELECT * FROM t1 WHERE c_bit IN (1, 2, 3);
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 range c_bit c_bit 2 NULL 3 Using where
EXPLAIN SELECT * FROM t1 WHERE c_bit IN (NULL, 1, 2, 3);
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 range c_bit c_bit 2 NULL 3 Using where
EXPLAIN SELECT * FROM t1 WHERE c_bit IN (NULL);
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE NULL NULL NULL NULL NULL NULL NULL Impossible WHERE noticed after reading const tables
EXPLAIN SELECT * FROM t1 WHERE c_bit IN (NULL, NULL);
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE NULL NULL NULL NULL NULL NULL NULL Impossible WHERE noticed after reading const tables
EXPLAIN SELECT * FROM t1 WHERE c_date
IN ('2009-09-01', '2009-09-02', '2009-09-03');
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 range c_date c_date 3 NULL 3 Using where
EXPLAIN SELECT * FROM t1 WHERE c_date
IN (NULL, '2009-09-01', '2009-09-02', '2009-09-03');
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 range c_date c_date 3 NULL 3 Using where
EXPLAIN SELECT * FROM t1 WHERE c_date IN (NULL);
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE NULL NULL NULL NULL NULL NULL NULL Impossible WHERE noticed after reading const tables
EXPLAIN SELECT * FROM t1 WHERE c_date IN (NULL, NULL);
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE NULL NULL NULL NULL NULL NULL NULL Impossible WHERE noticed after reading const tables
EXPLAIN SELECT * FROM t1 WHERE c_datetime
IN ('2009-09-01 00:00:01', '2009-09-02 00:00:01', '2009-09-03 00:00:01');
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 range c_datetime c_datetime 8 NULL 3 Using where
EXPLAIN SELECT * FROM t1 WHERE c_datetime
IN (NULL, '2009-09-01 00:00:01', '2009-09-02 00:00:01', '2009-09-03 00:00:01');
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 range c_datetime c_datetime 8 NULL 3 Using where
EXPLAIN SELECT * FROM t1 WHERE c_datetime IN (NULL);
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE NULL NULL NULL NULL NULL NULL NULL Impossible WHERE noticed after reading const tables
EXPLAIN SELECT * FROM t1 WHERE c_datetime IN (NULL, NULL);
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE NULL NULL NULL NULL NULL NULL NULL Impossible WHERE noticed after reading const tables
EXPLAIN SELECT * FROM t1 WHERE c_timestamp
IN ('2009-09-01 00:00:01', '2009-09-01 00:00:02', '2009-09-01 00:00:03');
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 range c_timestamp c_timestamp 4 NULL 3 Using where
EXPLAIN SELECT * FROM t1 WHERE c_timestamp
IN (NULL, '2009-09-01 00:00:01', '2009-09-01 00:00:02', '2009-09-01 00:00:03');
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 range c_timestamp c_timestamp 4 NULL 3 Using where
EXPLAIN SELECT * FROM t1 WHERE c_timestamp IN (NULL);
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE NULL NULL NULL NULL NULL NULL NULL Impossible WHERE noticed after reading const tables
EXPLAIN SELECT * FROM t1 WHERE c_timestamp IN (NULL, NULL);
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE NULL NULL NULL NULL NULL NULL NULL Impossible WHERE noticed after reading const tables
EXPLAIN SELECT * FROM t1 WHERE c_year IN (1, 2, 3);
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 range c_year c_year 1 NULL 3 Using where
EXPLAIN SELECT * FROM t1 WHERE c_year IN (NULL, 1, 2, 3);
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 range c_year c_year 1 NULL 3 Using where
EXPLAIN SELECT * FROM t1 WHERE c_year IN (NULL);
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE NULL NULL NULL NULL NULL NULL NULL Impossible WHERE noticed after reading const tables
EXPLAIN SELECT * FROM t1 WHERE c_year IN (NULL, NULL);
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE NULL NULL NULL NULL NULL NULL NULL Impossible WHERE noticed after reading const tables
EXPLAIN SELECT * FROM t1 WHERE c_char IN ('1', '2', '3');
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 range c_char c_char 10 NULL 3 Using where
EXPLAIN SELECT * FROM t1 WHERE c_char IN (NULL, '1', '2', '3');
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 range c_char c_char 10 NULL 3 Using where
EXPLAIN SELECT * FROM t1 WHERE c_char IN (NULL);
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE NULL NULL NULL NULL NULL NULL NULL Impossible WHERE noticed after reading const tables
EXPLAIN SELECT * FROM t1 WHERE c_char IN (NULL, NULL);
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE NULL NULL NULL NULL NULL NULL NULL Impossible WHERE noticed after reading const tables
DROP TABLE t1;
#
End of 5.1 tests