summaryrefslogtreecommitdiff
path: root/mysql-test/r/select.result
Commit message (Collapse)AuthorAgeFilesLines
* MDEV-8706 Wrong result for SELECT..WHERE time_column=TIMESTAMP'2015-08-30 ↵Alexander Barkov2015-09-091-1/+0
| | | | 00:00:00' AND time_column='00:00:00'
* Ensure that fields declared with NOT NULL doesn't have DEFAULT values if not ↵Monty2015-08-181-3/+3
| | | | | | | | | | | | | | | | | | specified and if not timestamp or auto_increment In original code, sometimes one got an automatic DEFAULT value in some cases, in other cases not. For example: create table t1 (a int primary key) - No default create table t2 (a int, primary key(a)) - DEFAULT 0 create table t1 SELECT .... - Default for all fields, even if they where defined as NOT NULL ALTER TABLE ... MODIFY could sometimes add an unexpected DEFAULT value. The patch is quite big because we had some many test cases that used CREATE ... SELECT or CREATE ... (...PRIMARY KEY(xxx)) which doesn't have an automatic DEFAULT anymore. Other things: - Removed warnings from InnoDB when waiting from semaphore (got this when testing things with --big)
* Bug #13571700 TINYBLOB NOT NULL, CRASH IN PROTOCOL::NET_STORE_DATASergey Petrunya2014-03-071-0/+8
| | | | - Backport testcase from mysql-5.6
* Bug#45227: Lost HAVING clause led to a wrong result.Sergey Petrunya2014-03-071-0/+31
| | | | - Backport testcase from mysql-5.6
* 10.0-base mergeSergei Golubchik2014-02-261-3/+3
|\
| * 5.5 mergeSergei Golubchik2014-02-251-3/+3
| |\
| | * 5.3 mergeSergei Golubchik2014-02-221-3/+3
| | |\
| | | * After constant row substitution the optimizer should call the methodIgor Babaev2014-02-201-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | update_used_tables for the the where condition to update cached indicators of constant subexpressions. It should be done before further possible simplification of the where condition. This change caused simplification of the executed where conditions in many test cases.
* | | | 10.0-base mergeSergei Golubchik2013-12-161-1/+1
|\ \ \ \ | |/ / /
| * | | 5.5 mergeSergei Golubchik2013-11-231-1/+1
| |\ \ \ | | |/ /
| | * | Merge 5.3->5.5Igor Babaev2013-11-211-1/+1
| | |\ \ | | | |/
| | | * Another attempt to fix bug mdev-5103.Igor Babaev2013-11-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The earlier pushed fix for the bug was incomplete. It did not remove the main cause of the problem: the function remove_eq_conds() removed always true multiple equalities from any conjunct, but did not adjust the list of them stored in Item_cond_and::cond_equal.current_level. Simplified the test case for the bug and moved it to another test file. The fix triggered changes in EXPLAIN EXTENDED for some queries.
* | | | 10.0-base merge.Sergei Golubchik2013-09-211-1/+148
|\ \ \ \ | |/ / / | | | | | | | | | | | | Partitioning/InnoDB changes are *not* merged (they'll come from 5.6) TokuDB does not compile (not updated to 10.0 SE API)
| * | | 5.5 merge and fixes for compiler/test errorsSergei Golubchik2013-09-181-1/+113
| |\ \ \ | | |/ /
| | * | Merge 5.3->5.5Igor Babaev2013-08-311-0/+25
| | |\ \ | | | |/
| | | * Fixed bug mdev-4971.Igor Babaev2013-08-291-0/+25
| | | | | | | | | | | | | | | | | | | | The function propagate_new_equalities() did not updated properly the references to inherited multiple equalities.
| | * | Merge 5.3->5.5Igor Babaev2013-08-271-1/+20
| | |\ \ | | | |/
| | | * Fixed bug mdev-4944.Igor Babaev2013-08-261-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The patch to fix mdev-4418 turned out to be incorrect. At the substitution of single row tables in make_join_statistics() the used multiple equalities may change and references to the new multiple equalities must be updated. The function remove_eq_conds() takes care of it and it should be called right after the substitution of single row tables. Calling it after the call of make_join_statistics was a mistake.
| | * | Merge 5.3->5.5.Igor Babaev2013-08-181-2/+70
| | |\ \ | | | |/ | | | | | | | | | | | | | | | | | | | | In particular: Merged the patch for bug mdev-4418 from 5.3 into 5.5. Fixed a bug in the patch that should be backported to 5.3.
| | | * Fixed bug mdev-4418.Igor Babaev2013-08-161-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | After single row substitutions there might appear new equalities. They should be properly propagated to all AND/OR levels the WHERE condition. It's done now with an additional call of remove_eq_conds().
| | | * Fixed bug mdev-4355.Igor Babaev2013-08-151-1/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch almost totally revised the patch for bug mdev-4177. The latter had too many defects. In particular, it did not propagate multiple equalities formed when merging a degenerate disjunct into underlying AND formula.
| * | | merge 5.5 -> 10.0-baseunknown2013-08-201-0/+35
| |/ /
* | | MDEV-4865 Change related to --log option/variable was merged partiallySergei Golubchik2013-08-131-4/+4
| | | | | | | | | | | | | | | Complete the merge of magne.mahre@oracle.com-20101102115354-vxcaxminmzglzalk (WL#5185 Remove deprecated 5.1 features)
* | | 10.0-monty mergeSergei Golubchik2013-07-211-3/+9
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | includes: * remove some remnants of "Bug#14521864: MYSQL 5.1 TO 5.5 BUGS PARTITIONING" * introduce LOCK_share, now LOCK_ha_data is strictly for engines * rea_create_table() always creates .par file (even in "frm-only" mode) * fix a 5.6 bug, temp file leak on dummy ALTER TABLE
| * | temporal-related changes. don't apply sql_mode flags on the lower level ↵Sergei Golubchik2013-07-111-6/+8
| | | | | | | | | | | | | | | | | | | | | | | | (str_to_datetime), do it on the upper level, in items that return temporal values. update tests results to match 5.6 better and to fix old bugs.
| * | fix cast.test, select.test, select_jcl6.test: update results after ↵Sergei Golubchik2013-07-101-1/+5
| | | | | | | | | | | | strict_date_checking=1
* | | The bugAlexander Barkov2013-05-081-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MDEV-4489 "Replication of big5, cp932, gbk, sjis strings makes wrong values on slave" has been fixed. Problem: String constants of some Asian charsets (big5,cp932,gbk,sjis) can have backslash '\' (0x5C) in the second byte of multi-byte characters. Replicating of such constants using the standard '\'-escaping is dangerous. Therefore, constants of these charsets are replicated using hex notation: INSERT INTO t1 (a) VALUES (0x815C); However, 0xHHHH constants do not work well in some cases, because they can behave as strings and as numbers, depending on context (for example, depending on the data type of the column in an INSERT statement). This SQL script was not replicated correctly with statement-based replication: SET NAMES gbk; PREPARE STMT FROM 'INSERT INTO t1 (a) VALUES (?)'; SET @a = '1'; EXECUTE STMT USING @a; The INSERT statement was replicated as: INSERT INTO t1 (a) VALUES (0x31); '1' was correctly converted to the number 1 on master. But the 0x31 constant was treated as number 49 on slave. Fix: 1. Binary log now uses X'HHHH' instead of 0xHHHH constants. 2. The X'HHHH' constants now work always as strings, in all contexts. This is the SQL standard compliant behaviour. After the fix, the above statement is replicated as: INSERT INTO t1 (a) VALUES (X'31'); X'31' is treated as string '1' on slave, and is correctly converted to 1. modified: @ mysql-test/r/ctype_cp932_binlog_stm.result @ mysql-test/r/select.result @ mysql-test/r/select_jcl6.result @ mysql-test/r/select_pkeycache.result @ mysql-test/r/user_var-binlog.result @ mysql-test/r/varbinary.result @ mysql-test/suite/binlog/r/binlog_stm_ctype_ucs.result @ mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result @ mysql-test/suite/rpl/r/rpl_charset_sjis.result @ mysql-test/suite/rpl/r/rpl_mdev382.result @ mysql-test/suite/rpl/t/rpl_charset_sjis.test @ mysql-test/t/ctype_cp932_binlog_stm.test @ mysql-test/t/select.test @ mysql-test/t/varbinary.test Adding and updating tests @ sql/item.cc @ sql/item.h @ sql/sql_yacc.yy @ sql/sql_lex.cc Splitting the implementations of X'HH' and 0xHH constants into two separate classes. Fixing the parser to distinguish the two syntaxes. @ sql/log_event.cc Using X'HH' instead of 0xHH for binary logging for string constants of the "dangerous" charsets. @ sql/sql_string.h Adding a helped method String::append_hex().
* | | Merge 5.3->5.5Igor Babaev2013-05-041-0/+35
|\ \ \ | | |/ | |/|
| * | Fixed bug mdev-4274.Igor Babaev2013-04-291-0/+35
| | | | | | | | | | | | | | | | | | | | | | | | This bug was the result of incompleteness of the patch for bug mdev-4177. When an OR condition is simplified to a single conjunct it is merged into the embedding AND condition. Multiple equalities are also merged, and any field item involved in those equality should acquire a pointer to a the multiple equality formed by this merge.
* | | 5.3->5.5 mergeSergei Golubchik2013-03-101-0/+20
|\ \ \ | |/ / | | / | |/ |/|
| * Fixed bug mdev-4250.Igor Babaev2013-03-081-0/+20
| | | | | | | | | | | | This is a bug in the legacy code. It did not manifest itself because it was masked by other bugs that were fixed by the patches for mdev-4172 and mdev-4177.
* | 5.3 mergeSergei Golubchik2012-10-181-24/+24
|\ \ | |/
| * Fixed LP bug #1058071 (mdev-564).Igor Babaev2012-09-291-24/+24
| | | | | | | | | | | | | | | | In some rare cases when the value of the system variable join_buffer_size was set to a number less than 256 the function JOIN_CACHE::set_constants determined the size of an offset in the join buffer equal to 1 though the minimal join buffer required more than 256 bytes. This could cause a crash of the server when records from the join buffer were read.
* | 5.3 mergeSergei Golubchik2012-05-211-0/+12
|\ \ | |/
| * LP bug#994275 fix.unknown2012-05-071-0/+12
| | | | | | | | | | In 5.3 we substitute constants in ref access values it can't be null so we do not need add NOT NULL for early NULL filtering.
* | Merge 5.3->5.5.Igor Babaev2012-03-011-2/+2
|\ \ | |/
| * Merge 5.2->5.3Sergey Petrunya2012-02-241-2/+2
| |\
| | * Back-ported the fix and test cases for bugs #59487 and #43368 fromIgor Babaev2012-02-221-2/+2
| | | | | | | | | | | | the mysql-5.6 code line.
* | | 5.3.4 mergeSergei Golubchik2012-02-151-4/+5
|\ \ \ | |/ /
| * | Merge 5.2->5.3 in preparation for the release of mariadb-5.3.4-rc.Igor Babaev2012-02-011-4/+4
| |\ \ | | |/
| | * Fixed LP bug #904345.Igor Babaev2011-12-271-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The MIN/MAX optimizer code from the function opt_sum_query erroneously did not take into account conjunctive conditions that did not depend on any table, yet were not identified as constant items. These could be items containing rand() or PS/SP parameters. These items are supposed to be evaluated at the execution phase. That's why if such conditions can be extracted from the WHERE condition the MIN/MAX optimization is not applied as currently it is always done at the optimization phase. (In 5.3 expensive subqueries are also evaluated only at the execution phase. So, if a constant condition with such subquery can be extracted from the WHERE clause the MIN/MAX optimization should not be applied in 5.3.) IF an IN/ALL/SOME predicate with a constant left part is transformed into an EXISTS subquery the resulting subquery should not be considered uncacheable if the right part of the predicate is not uncacheable. Backported the function dbug_print_item() from 5.3. The function is used only for debugging.
| * | Adjust test results after Monty's push of the newunknown2012-01-181-0/+1
| | | | | | | | | | | | handler counter Handler_read_rnd_deleted.
* | | mysql-5.5 mergeSergei Golubchik2012-01-161-0/+19
|\ \ \
| * | | Bug#13344643:Format function in view looses locale informationChaithra Gopalareddy2011-12-151-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem description: When a view is created using function FORMAT and if FORMAT function uses locale option,definition of view saved into server doesn't contain that locale information, Ex: create table test2 (bb decimal (10,2)); insert into test2 values (10.32),(10009.2),(12345678.21); create view test3 as select format(bb,1,'sk_SK') as cc from test2; select * from test3; +--------------+ | cc | +--------------+ | 10.3 | | 10,009.2 | | 12,345,678.2 | +--------------+ 3 rows in set (0.02 sec) show create view test3 View: test3 Create View: CREATE ALGORITHM=UNDEFINED DEFINER=`root`@`localhost` SQL SECURITY DEFINER VIEW `test3` AS select format(`test2`.`bb`,1) AS `cc` from `test2` character_set_client: latin1 collation_connection: latin1_swedish_ci 1 row in set (0.02 sec) Problem Analysis: The function Item_func_format::print() which prints the query string to create the view does not print the third argument (i.e the locale information). Hence view is created without locale information. Problem Solution: If argument count is more than 2 we now print the third argument onto the query string. Files changed: sql/item_strfunc.cc Function call changes: Item_func_format::print() mysql-test/t/select.test Added test case to test the bug mysql-test/r/select.result Result of the test case appended here
* | | | 5.3 mergeSergei Golubchik2012-01-131-2/+69
|\ \ \ \ | | |/ / | |/| |
| * | | Back-ported the patch of the mysql-5.6 code line thatIgor Babaev2011-12-241-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | fixed several defects in the greedy optimization: 1) The greedy optimizer calculated the 'compare-cost' (CPU-cost) for iterating over the partial plan result at each level in the query plan as 'record_count / (double) TIME_FOR_COMPARE' This cost was only used locally for 'best' calculation at each level, and *not* accumulated into the total cost for the query plan. This fix added the 'CPU-cost' of processing 'current_record_count' records at each level to 'current_read_time' *before* it is used as 'accumulated cost' argument to recursive best_extension_by_limited_search() calls. This ensured that the cost of a huge join-fanout early in the QEP was correctly reflected in the cost of the final QEP. To get identical cost for a 'best' optimized query and a straight_join with the same join order, the same change was also applied to optimize_straight_join() and get_partial_join_cost() 2) Furthermore to get equal cost for 'best' optimized query and a straight_join the new code substrcated the same '0.001' in optimize_straight_join() as it had been already done in best_extension_by_limited_search() 3) When best_extension_by_limited_search() aggregated the 'best' plan a plan was 'best' by the check : 'if ((search_depth == 1) || (current_read_time < join->best_read))' The term '(search_depth == 1' incorrectly caused a new best plan to be collected whenever the specified 'search_depth' was reached - even if this partial query plan was more expensive than what we had already found.
| * | | Made join_cache_level == 2 by default.Igor Babaev2011-12-151-0/+1
| | | |
| * | | Made the optimizer switch flags 'outer_join_with_cache', 'semijoin_with_cache'Igor Babaev2011-12-151-0/+3
| | | | | | | | | | | | | | | | set to 'on' by default.
| * | | Merge with 5.2.Michael Widenius2011-12-111-0/+27
| |\ \ \ | | | |/ | | |/| | | | | no_error handling for select (used by INSERT ... SELECT) still needs to be fixed, but I will do that in a separate commit
| | * | Fix for lp:780425 sql_buffer_result=1 gives wrong result for GROUP BY with a ↵Michael Widenius2011-11-151-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +# constant expression" mysql-test/r/select.result: Test case for lp:780425 mysql-test/r/select_pkeycache.result: lp:780425 mysql-test/t/select.test: lp:780425 sql/sql_select.cc: Added DBUG_ASSERT to be prove some logic and later be able to simplify the code Set implicit_grouping if we delete a GROUP BY to signal do_select() that a grouping needs to be done.
View Lorry Controller Status