mirror/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-02-01 11:31:51 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
mariadb/mysql-test/r/func_if.result

199 lines
5.4 KiB
Text
Raw Normal View History

Portability fixes
2002-04-26 08:56:28 +03:00
drop table if exists t1;
select IF(0,"ERROR","this"),IF(1,"is","ERROR"),IF(NULL,"ERROR","a"),IF(1,2,3)|0,IF(1,2.0,3.0)+0 ;
New if tests
2002-04-22 23:41:55 +03:00
IF(0,"ERROR","this") IF(1,"is","ERROR") IF(NULL,"ERROR","a") IF(1,2,3)|0 IF(1,2.0,3.0)+0
this is a 2 2.0
WorkLog#1323 Deprecate the use of TYPE=... Preferred syntax is ENGINE=
2003-12-10 04:31:42 +00:00
CREATE TABLE t1 (st varchar(255) NOT NULL, u int(11) NOT NULL) ENGINE=MyISAM;
Portability fixes
2002-04-26 08:56:28 +03:00
INSERT INTO t1 VALUES ('a',1),('A',1),('aa',1),('AA',1),('a',1),('aaa',0),('BBB',0);
select if(1,st,st) s from t1 order by s;
New if tests
2002-04-22 23:41:55 +03:00
s
a
A
a
aa
AA
aaa
BBB
Portability fixes
2002-04-26 08:56:28 +03:00
select if(u=1,st,st) s from t1 order by s;
New if tests
2002-04-22 23:41:55 +03:00
s
a
A
a
aa
AA
aaa
BBB
Portability fixes
2002-04-26 08:56:28 +03:00
select if(u=1,binary st,st) s from t1 order by s;
New if tests
2002-04-22 23:41:55 +03:00
s
A
AA
BBB
a
a
aa
aaa
Portability fixes
2002-04-26 08:56:28 +03:00
select if(u=1,st,binary st) s from t1 where st like "%a%" order by s;
New if tests
2002-04-22 23:41:55 +03:00
s
A
AA
a
a
aa
aaa
added code covarage for functions convert(), nullif(), crc32(), is_used_lock(), char_lengtrh(), bit_xor() added string length for more speed made code covarage for print() method of Item fixed printability of some items (SCRUM) (WL#1274)
2003-10-30 12:57:26 +02:00
explain extended select if(u=1,st,binary st) s from t1 where st like "%a%" order by s;
BUG#14940 "MySQL choose wrong index", v.2 - Make the range-et-al optimizer produce E(#table records after table condition is applied), - Make the join optimizer use this value, - Add "filtered" column to EXPLAIN EXTENDED to show fraction of records left after table condition is applied - Adjust test results, add comments
2006-07-28 21:27:01 +04:00
id select_type table type possible_keys key key_len ref rows filtered Extra
1 SIMPLE t1 ALL NULL NULL NULL NULL 7 100.00 Using where; Using filesort
added code covarage for functions convert(), nullif(), crc32(), is_used_lock(), char_lengtrh(), bit_xor() added string length for more speed made code covarage for print() method of Item fixed printability of some items (SCRUM) (WL#1274)
2003-10-30 12:57:26 +02:00
Warnings:
Fix for Bug#32538: View definition picks up character set, but not collation. The problem here was that text literals in a view were always dumped with character set introducer. That lead to loosing collation information. The fix is to dump character set introducer only if it was in the original query. That is now possible because there is no problem any more of loss of character set of string literals in views -- after WL#4052 the view is dumped in the original character set.
2008-02-12 22:09:16 +03:00
Note 1003 select if((`test`.`t1`.`u` = 1),`test`.`t1`.`st`,cast(`test`.`t1`.`st` as char charset binary)) AS `s` from `test`.`t1` where (`test`.`t1`.`st` like '%a%') order by if((`test`.`t1`.`u` = 1),`test`.`t1`.`st`,cast(`test`.`t1`.`st` as char charset binary))
Invalid DEFAULT values for CREATE TABLE now generates errors. (Bug #5902) CAST() now produces warnings when casting a wrong INTEGER or CHAR values. This also applies to implicite string to number casts. (Bug #5912) ALTER TABLE now fails in STRICT mode if it generates warnings. Inserting a zero date in a DATE, DATETIME or TIMESTAMP column during TRADITIONAL mode now produces an error. (Bug #5933)
2005-04-01 15:04:50 +03:00
select nullif(u, 1) from t1;
nullif(u, 1)
added code covarage for functions convert(), nullif(), crc32(), is_used_lock(), char_lengtrh(), bit_xor() added string length for more speed made code covarage for print() method of Item fixed printability of some items (SCRUM) (WL#1274)
2003-10-30 12:57:26 +02:00
NULL
NULL
NULL
NULL
NULL
Invalid DEFAULT values for CREATE TABLE now generates errors. (Bug #5902) CAST() now produces warnings when casting a wrong INTEGER or CHAR values. This also applies to implicite string to number casts. (Bug #5912) ALTER TABLE now fails in STRICT mode if it generates warnings. Inserting a zero date in a DATE, DATETIME or TIMESTAMP column during TRADITIONAL mode now produces an error. (Bug #5933)
2005-04-01 15:04:50 +03:00
0
0
explain extended select nullif(u, 1) from t1;
BUG#14940 "MySQL choose wrong index", v.2 - Make the range-et-al optimizer produce E(#table records after table condition is applied), - Make the join optimizer use this value, - Add "filtered" column to EXPLAIN EXTENDED to show fraction of records left after table condition is applied - Adjust test results, add comments
2006-07-28 21:27:01 +04:00
id select_type table type possible_keys key key_len ref rows filtered Extra
1 SIMPLE t1 ALL NULL NULL NULL NULL 7 100.00
added code covarage for functions convert(), nullif(), crc32(), is_used_lock(), char_lengtrh(), bit_xor() added string length for more speed made code covarage for print() method of Item fixed printability of some items (SCRUM) (WL#1274)
2003-10-30 12:57:26 +02:00
Warnings:
Invalid DEFAULT values for CREATE TABLE now generates errors. (Bug #5902) CAST() now produces warnings when casting a wrong INTEGER or CHAR values. This also applies to implicite string to number casts. (Bug #5912) ALTER TABLE now fails in STRICT mode if it generates warnings. Inserting a zero date in a DATE, DATETIME or TIMESTAMP column during TRADITIONAL mode now produces an error. (Bug #5933)
2005-04-01 15:04:50 +03:00
Note 1003 select nullif(`test`.`t1`.`u`,1) AS `nullif(u, 1)` from `test`.`t1`
Portability fixes
2002-04-26 08:56:28 +03:00
drop table t1;
Invalid DEFAULT values for CREATE TABLE now generates errors. (Bug #5902) CAST() now produces warnings when casting a wrong INTEGER or CHAR values. This also applies to implicite string to number casts. (Bug #5912) ALTER TABLE now fails in STRICT mode if it generates warnings. Inserting a zero date in a DATE, DATETIME or TIMESTAMP column during TRADITIONAL mode now produces an error. (Bug #5933)
2005-04-01 15:04:50 +03:00
select nullif(1,'test');
nullif(1,'test')
1
Warnings:
Warning 1292 Truncated incorrect DOUBLE value: 'test'
Fix for bug #2629 NULLIF() doesn't behave as described in manual
2004-03-16 11:33:03 +04:00
select NULLIF(NULL,NULL), NULLIF(NULL,1), NULLIF(NULL,1.0), NULLIF(NULL,"test");
NULLIF(NULL,NULL) NULLIF(NULL,1) NULLIF(NULL,1.0) NULLIF(NULL,"test")
NULL NULL NULL NULL
select NULLIF(1,NULL), NULLIF(1.0, NULL), NULLIF("test", NULL);
NULLIF(1,NULL) NULLIF(1.0, NULL) NULLIF("test", NULL)
1 1.0 test
Portability fixes
2002-04-26 08:56:28 +03:00
create table t1 (num double(12,2));
insert into t1 values (144.54);
select sum(if(num is null,0.00,num)) from t1;
New if tests
2002-04-22 23:41:55 +03:00
sum(if(num is null,0.00,num))
Portability fixes
2002-04-26 08:56:28 +03:00
144.54
drop table t1;
Fixes after last merge
2002-08-12 07:02:08 +03:00
create table t1 (x int, y int);
insert into t1 values (0,6),(10,16),(20,26),(30,10),(40,46),(50,56);
select min(if(y -x > 5,y,NULL)), max(if(y - x > 5,y,NULL)) from t1;
min(if(y -x > 5,y,NULL)) max(if(y - x > 5,y,NULL))
6 56
drop table t1;
BUG#3987 - if(int, aggregate(int))
2004-06-07 12:38:35 +02:00
create table t1 (a int);
insert t1 values (1),(2);
select if(1>2,a,avg(a)) from t1;
if(1>2,a,avg(a))
1.5000
drop table t1;
Fix for bug #5595: NULLIF() IS NULL returns false if NULLIF() returns NULL
2004-09-18 13:06:44 +04:00
SELECT NULLIF(5,5) IS NULL, NULLIF(5,5) IS NOT NULL;
NULLIF(5,5) IS NULL NULLIF(5,5) IS NOT NULL
1 0
Fix bug #9669 Ordering on IF function with FROM_UNIXTIME function fails Integer overflow results in wrong field sortlength.
2005-06-02 17:00:07 +04:00
CREATE TABLE `t1` (
`id` int(11) NOT NULL ,
`date` int(10) default NULL,
`text` varchar(32) NOT NULL
);
INSERT INTO t1 VALUES (1,1110000000,'Day 1'),(2,1111000000,'Day 2'),(3,1112000000,'Day 3');
SELECT id, IF(date IS NULL, '-', FROM_UNIXTIME(date, '%d-%m-%Y')) AS date_ord, text FROM t1 ORDER BY date_ord ASC;
id date_ord text
1 05-03-2005 Day 1
2 16-03-2005 Day 2
3 28-03-2005 Day 3
SELECT id, IF(date IS NULL, '-', FROM_UNIXTIME(date, '%d-%m-%Y')) AS date_ord, text FROM t1 ORDER BY date_ord DESC;
id date_ord text
3 28-03-2005 Day 3
2 16-03-2005 Day 2
1 05-03-2005 Day 1
DROP TABLE t1;
func_if.result, func_if.test: Added a test case for bug #11142. item_cmpfunc.cc: Fixed bug #11142. Implementation of Item_func_nullif::is_null was corrected.
2005-06-13 11:24:26 -07:00
CREATE TABLE t1 (a CHAR(10));
INSERT INTO t1 VALUES ('aaa'), (NULL), (''), ('bbb');
SELECT a, NULLIF(a,'') FROM t1;
a NULLIF(a,'')
aaa aaa
NULL NULL
NULL
bbb bbb
SELECT a, NULLIF(a,'') FROM t1 WHERE NULLIF(a,'') IS NULL;
a NULLIF(a,'')
NULL NULL
NULL
DROP TABLE t1;
Fixed bug#16272: IF function with decimal args can produce wrong result The Item_func_if::fix_length_and_dec() function when calculating length of result doesn't take into account unsigned_flag. But it is taken when calculating length of temporary field. This result in creating field that shorter than needed. Due to this, in the reported query 40.0 converted to 9.99. The function Item_func_if::fix_length_and_dec() now adds 1 to the max_length if the unsigned_flag isn't set.
2006-02-14 16:22:37 +03:00
create table t1 (f1 int, f2 int);
insert into t1 values(1,1),(0,0);
select f1, f2, if(f1, 40.0, 5.00) from t1 group by f1 order by f2;
f1 f2 if(f1, 40.0, 5.00)
0 0 5.00
1 1 40.00
drop table t1;
Bug#24532 (The return data type of IS TRUE is different from similar operations) Before this change, the boolean predicates: - X IS TRUE, - X IS NOT TRUE, - X IS FALSE, - X IS NOT FALSE were implemented by expanding the Item tree in the parser, by using a construct like: Item_func_if(Item_func_ifnull(X, <value>), <value>, <value>) Each <value> was a constant integer, either 0 or 1. A bug in the implementation of the function IF(a, b, c), in Item_func_if::fix_length_and_dec(), would cause the following : When the arguments b and c are both unsigned, the result type of the function was signed, instead of unsigned. When the result of the if function is signed, space for the sign could be counted twice (in the max() expression for a signed argument, and in the total), causing the member max_length to be too high. An effect of this is that the final type of IF(x, int(1), int(1)) would be int(2) instead of int(1). With this fix, the problems found in Item_func_if::fix_length_and_dec() have been fixed. While it's semantically correct to represent 'X IS TRUE' with Item_func_if(Item_func_ifnull(X, <value>), <value>, <value>), there are however more problems with this construct. a) Building the parse tree involves : - creating 5 Item instances (3 ints, 1 ifnull, 1 if), - creating each Item calls my_pthread_getspecific_ptr() once in the operator new(size), and a second time in the Item::Item() constructor, resulting in a total of 10 calls to get the current thread. Evaluating the expression involves evaluating up to 4 nodes at runtime. This representation could be greatly simplified and improved. b) Transforming the parse tree internally with if(ifnull(...)) is fine as long as this transformation is internal to the server implementation. With views however, the result of the parse tree is later exposed by the ::print() functions, and stored as part of the view definition. Doing this has long term consequences: 1) The original semantic 'X IS TRUE' is lost, and replaced by the if(ifnull(...)) expression. As a result, SHOW CREATE VIEW does not restore the original code. 2) Should a future version of MySQL implement the SQL BOOLEAN data type for example, views created today using 'X IS NULL' can be exported using mysqldump, and imported again. Such views would be converted correctly and automatically to use a BOOLEAN column in the future version. With 'X IS TRUE' and the current implementations, views using these "boolean" predicates would not be converted during the export/import, and would use integer columns instead. The difference traces back to how SHOW CREATE VIEW preserves 'X IS NULL' but does not preserve the 'X IS TRUE' semantic. With this fix, internal representation of 'X IS TRUE' booleans predicates has changed, so that: - dedicated Item classes are created for each predicate, - only 1 Item is created to represent 1 predicate - my_pthread_getspecific_ptr() is invoked 1 time instead of 10 - SHOW CREATE VIEW preserves the original semantic, and prints 'X IS TRUE'. Note that, because of the fix in Item_func_if, views created before this fix will: - correctly use a int(1) type instead of int(2) for boolean predicates, - incorrectly print the if(ifnull(...), ...) expression in SHOW CREATE VIEW, since the original semantic (X IS TRUE) has been lost. - except for the syntax used in SHOW CREATE VIEW, these views will operate properly, no action is needed. Views created after this fix will operate correctly, and will preserve the original code semantic in SHOW CREATE VIEW.
2007-02-12 13:59:29 -07:00
select if(0, 18446744073709551610, 18446744073709551610);
if(0, 18446744073709551610, 18446744073709551610)
18446744073709551610
Bug#37662 nested if() inside sum() is parsed in exponential time min() and max() functions are implemented in MySQL as macros. This means that max(a,b) is expanded to: ((a) > (b) ? (a) : (b)) Note how 'a' is quoted two times. Now imagine 'a' is a recursive function call that's several 10s of levels deep. And the recursive function does max() with a function arg as well to dive into recursion. This means that simple function call can take most of the clock time. Identified and fixed several such calls to max()/min() : including the IF() sql function implementation.
2008-07-30 14:07:37 +03:00
CREATE TABLE t1(a DECIMAL(10,3));
SELECT t1.a,
IF((ROUND(t1.a,2)=1), 2,
IF((ROUND(t1.a,2)=1), 2,
IF((ROUND(t1.a,2)=1), 2,
IF((ROUND(t1.a,2)=1), 2,
IF((ROUND(t1.a,2)=1), 2,
IF((ROUND(t1.a,2)=1), 2,
IF((ROUND(t1.a,2)=1), 2,
IF((ROUND(t1.a,2)=1), 2,
IF((ROUND(t1.a,2)=1), 2,
IF((ROUND(t1.a,2)=1), 2,
IF((ROUND(t1.a,2)=1), 2,
IF((ROUND(t1.a,2)=1), 2,
IF((ROUND(t1.a,2)=1), 2,
IF((ROUND(t1.a,2)=1), 2,
IF((ROUND(t1.a,2)=1), 2,
IF((ROUND(t1.a,2)=1), 2,
IF((ROUND(t1.a,2)=1), 2,
IF((ROUND(t1.a,2)=1), 2,
IF((ROUND(t1.a,2)=1), 2,
IF((ROUND(t1.a,2)=1), 2,
IF((ROUND(t1.a,2)=1), 2,
IF((ROUND(t1.a,2)=1), 2,
IF((ROUND(t1.a,2)=1), 2,
IF((ROUND(t1.a,2)=1), 2,
IF((ROUND(t1.a,2)=1), 2,
IF((ROUND(t1.a,2)=1), 2,
IF((ROUND(t1.a,2)=1), 2,
IF((ROUND(t1.a,2)=1), 2,
IF((ROUND(t1.a,2)=1), 2,
IF((ROUND(t1.a,2)=1), 2,0)))))))))))))))))))))))))))))) + 1
FROM t1;
a IF((ROUND(t1.a,2)=1), 2,
IF((ROUND(t1.a,2)=1), 2,
IF((ROUND(t1.a,2)=1), 2,
IF((ROUND(t1.a,2)=1), 2,
IF((ROUND(t1.a,2)=1), 2,
IF((ROUND(t1.a,2)=1), 2,
IF((ROUND(t1.a,2)=1), 2,
IF((ROUND(t1.a,2)=1), 2,
IF((ROUND(t1.a,2)=1), 2,
IF((ROUND(t1.a,2)=1), 2,
IF((R
DROP TABLE t1;
Bug #40761: Assert on sum function on IF(..., CAST(longtext AS UNSIGNED), signed_val) (was: LEFT JOIN on inline view crashes server) Select from a LONGTEXT column wrapped with an expression like "IF(..., CAST(longtext_column AS UNSIGNED), smth_signed)" failed an assertion or crashed the server. IFNULL function was affected too. LONGTEXT column item has a maximum length of 32^2-1 bytes, at the same time this is a maximum possible length of any MySQL item. CAST(longtext_column AS UNSIGNED) returns some unsigned numeric result of length 32^2-1, so the result of IF/IFNULL function of this number and some other signed number will have text length of (32^2-1)+1=32^2 (one byte for the minus sign) - there is integer overflow, and the length is equal to zero. That caused assert/crash. CAST AS UNSIGNED function has been modified to limit maximal length of resulting number to 67 (maximal length of DECIMAL and two characters for minus sign and dot).
2008-12-12 17:16:25 +04:00
CREATE TABLE t1 (c LONGTEXT);
INSERT INTO t1 VALUES(1), (2), (3), (4), ('12345678901234567890');
SELECT * FROM (SELECT MAX(IF(1, CAST(c AS UNSIGNED), 0)) FROM t1) AS te;
MAX(IF(1, CAST(c AS UNSIGNED), 0))
12345678901234567890
SELECT * FROM (SELECT MAX(IFNULL(CAST(c AS UNSIGNED), 0)) FROM t1) AS te;
MAX(IFNULL(CAST(c AS UNSIGNED), 0))
12345678901234567890
DROP TABLE t1;
Bug#37662 nested if() inside sum() is parsed in exponential time min() and max() functions are implemented in MySQL as macros. This means that max(a,b) is expanded to: ((a) > (b) ? (a) : (b)) Note how 'a' is quoted two times. Now imagine 'a' is a recursive function call that's several 10s of levels deep. And the recursive function does max() with a function arg as well to dive into recursion. This means that simple function call can take most of the clock time. Identified and fixed several such calls to max()/min() : including the IF() sql function implementation.
2008-07-30 14:07:37 +03:00
End of 5.0 tests
Bug#55077: Assertion failed: width > 0 && to != ((void *)0), file .\dtoa.c The assertion failure was correct because the 'width' argument of my_gcvt() has the signed integer type, whereas the unsigned value UINT_MAX32 was being passed by the caller (Field_double::val_str()) leading to a negative width in my_gcvt(). The following chain of problems was found by further analysis: 1. The display width for a floating point number is calculated in Field_double::val_str() as either field_length or the maximum possible length of string representation of a floating point number, whichever is greater. Since in the bug's test case field_length is UINT_MAX32, we get the same value as the display width. This does not make any sense because for numeric values field_length only matters for ZEROFILL columns, otherwise it does not make sense to allocate that much memory just to print a number. Field_float::val_str() has a similar problem. 2. Even if the above wasn't the case, we would still get a crash on a slightly different test case when trying to allocate UINT_MAX32 bytes with String::alloc() because the latter does not handle such large input values correctly due to alignment overflows. 3. Even when String::alloc() is fixed to return an error when an alignment overflow occurs, there is still a problem because almost no callers check its return value, and Field_double::val_str() is not an exception (same for Field_float::val_str()). 4. Even if all of the above wasn't the case, creating a Field_double object with UINT_MAX32 as its field_length does not make much sense either, since the .frm code limits it to MAX_FIELD_CHARLENGTH (255) bytes. Such a beast can only be created by create_tmp_field_from_item() from an Item with REAL_RESULT as its result_type() and UINT_MAX32 as its max_length. 5. For the bug's test case, the above condition (REAL_RESULT Item with max_length = UINT_MAX32) was a result of Item_func_if::fix_length_and_dec() "shortcutting" aggregation of argument types when one of the arguments was a constant NULL. In this case, the attributes of the aggregated type were simply copied from the other, non-NULL argument, but max_length was still calculated as per the general, non-shortcut case, by choosing the greatest of argument's max_length, which is obviously not correct. The patch addresses all of the above problems, even though fixing the assertion failure for the particular test case would require only a subset of the above problems to be solved.
2010-08-25 19:57:53 +04:00
#
# Bug#55077: Assertion failed: width > 0 && to != ((void *)0), file .\dtoa.c
#
CREATE TABLE t1 (a LONGBLOB, b DOUBLE);
INSERT INTO t1 VALUES (NULL, 0), (NULL, 1);
SELECT IF(b, (SELECT a FROM t1 LIMIT 1), b) c FROM t1 GROUP BY c;
c
NULL
0
DROP TABLE t1;
Reference in a new issue Copy permalink