statement that uses an aggregating IN subquery with
HAVING clause.
A wrong order of the call of split_sum_func2 for the HAVING
clause of the subquery and the transformation for the
subquery resulted in the creation of a andor structure
that could not be restored at an execution of the prepared
statement.
mysql-test/r/ps.result:
Added a test cases for bug #22085.
mysql-test/t/ps.test:
Added a test cases for bug #22085.
into macbook.gmz:/Users/kgeorge/mysql/work/B21180-4.1-opt
mysql-test/r/subselect.result:
merge of 4.1-opt
mysql-test/t/subselect.test:
merge of 4.1-opt
sql/opt_range.h:
merge of 4.1-opt
Added the test case for bug#21677: Wrong result when comparing a DATE and a DATETIME in BETWEEN
mysql-test/t/type_date.test:
Added the test case for bug#21677: Wrong result when comparing a DATE and a DATETIME in BETWEEN
mysql-test/r/type_date.result:
Added the test case for bug#21677: Wrong result when comparing a DATE and a DATETIME in BETWEEN
Removed changes to the Item_func_between::fix_length_and_dec() made in the fix for bug#16377
query_cache.result:
Corrected a test case after removing a fix for bug#16377
mysql-test/r/query_cache.result:
Corrected a test case after removing a fix for bug#16377
sql/item_cmpfunc.cc:
Removed changes to the Item_func_between::fix_length_and_dec() made in the fix for bug#16377
VALUES() was considered a constant. This caused replacing
(or pre-calculating) it using uninitialized values before the actual
execution takes place.
Mark it as a non-constant (still not dependent of tables) to prevent
the pre-calculation.
mysql-test/r/insert_update.result:
Bug#21555: incorrect behavior with INSERT ... ON DUPL KEY UPDATE and VALUES
- test case.
- EXPLAIN output changed due to VALUES() not being considered a constant
anymore
mysql-test/t/insert_update.test:
Bug#21555: incorrect behavior with INSERT ... ON DUPL KEY UPDATE and VALUES
- test case.
sql/item.h:
Bug#21555: incorrect behavior with INSERT ... ON DUPL KEY UPDATE and VALUES
- mark Item_insert_value as non-constant to prevent early calculation.
Corrected test case after removal of fix for bug#16377
type_date.test:
Corrected test case after removal of fix for bug#16377
item_cmpfunc.cc:
Removed changes to the agg_cmp_type() made in the for bug#16377
mysql-test/t/type_date.test:
Corrected test case after removal of fix for bug#16377
mysql-test/t/func_time.test:
Corrected test case after removal of fix for bug#16377
mysql-test/r/type_date.result:
Corrected test case after removal of fix for bug#16377
mysql-test/r/query_cache.result:
Corrected test case after removal of fix for bug#16377
mysql-test/r/func_time.result:
Corrected test case after removal of fix for bug#16377
sql/item_cmpfunc.cc:
Removed changes to the agg_cmp_type() made in the for bug#16377
1003: Incorrect table name
in multi-table DELETE the set of tables to delete from actually
references then tables in the other list, e.g:
DELETE alias_of_t1 FROM t1 alias_of_t1 WHERE ....
is a valid statement.
So we must turn off table name syntactical validity check for alias_of_t1
because it's not a table name (even if it looks like one).
In order to do that we add a special flag (TL_OPTION_ALIAS) to
disable the name checking for the aliases in multi-table DELETE.
mysql-test/r/delete.result:
Bug #21392: multi-table delete with alias table name fails with
1003: Incorrect table name
- test case
mysql-test/t/delete.test:
Bug #21392: multi-table delete with alias table name fails with
1003: Incorrect table name
- test case
sql/mysql_priv.h:
Bug #21392: multi-table delete with alias table name fails with
1003: Incorrect table name
- add a special flag to disable the name checking for the aliases
in multi-table DELETE
sql/sql_parse.cc:
Bug #21392: multi-table delete with alias table name fails with
1003: Incorrect table name
- add a special flag to disable the name checking for the aliases
in multi-table DELETE
sql/sql_yacc.yy:
Bug #21392: multi-table delete with alias table name fails with
1003: Incorrect table name
- add a special flag to disable the name checking for the aliases
in multi-table DELETE
fix deadlock if master switches log file in parallell with "show master logs"
sql/log.cc:
add raw_get_current_log which dont take log mutex
sql/sql_class.h:
add raw_get_current_log which dont take log mutex
sql/sql_repl.cc:
Fix lock order i.e first log_lock then index_lock
The problem was due to a prior fix for BUG 9676, which limited
the rows stored in a temporary table to the LIMIT clause. This
optimization is not applicable to non-group queries with aggregate
functions. The fix disables the optimization in this case.
mysql-test/r/limit.result:
Test case for BUG#21787
mysql-test/t/limit.test:
Test case for BUG#21787
sql/sql_select.cc:
If there is an aggregate function in a non-group query,
materialize all rows in the temporary table no matter if
there is a LIMIT clause. This is necessary, since the
aggregate functions must be computed over all result rows,
not just the first LIMIT rows.
- Dont test "encrypt" in ctype_ucs
mysql-test/r/ctype_ucs.result:
Don't test "encrypt" function in ctype_ucs.test
mysql-test/t/ctype_ucs.test:
Don't test "encrypt" function in ctype_ucs.test
single file is a bad practice.
tests/mysql_client_test.c:
Replace literal characters which don't make sense in UTF8 with ubiquitously-
understood numbers.
event' from master"
Since there is no repeatable test case, and this is obviously wrong, this is
the most conservative change that might possibly work.
The syscall read() wasn't checked for a negative return value for an
interrupted read. The kernel sys_read() returns -EINTR, and the "library"
layer maps that to return value of -1 and sets errno to EINTR. It's
impossible (on Linux) for read() to set errno EINTR without the return
value being -1 .
So, if we're checking for EINTR behavior, we should not require that the
return value be zero.
mysys/my_read.c:
The read() syscall should check for negative one, since that (usually) signals
errors (like being interrupted) and zero (usually) signals end-of-file .
Bug#21432 Database/Table name limited to 64 bytes, not chars, problems with multi-byte
include/mysql_com.h:
Bug#20393 User name truncation in mysql client
Bug#21432 Database/Table name limited to 64 bytes, not chars, problems with multi-byte
added new constants NAME_BYTE_LEN, USERNAME_BYTE_LENGTH, SYSTEM_CHARSET_MBMAXLEN
mysql-test/r/ctype_utf8.result:
Bug#20393 User name truncation in mysql client
Bug#21432 Database/Table name limited to 64 bytes, not chars, problems with multi-byte
test case
mysql-test/t/ctype_utf8.test:
Bug#20393 User name truncation in mysql client
Bug#21432 Database/Table name limited to 64 bytes, not chars, problems with multi-byte
test case
sql-common/client.c:
Bug#20393 User name truncation in mysql client
Bug#21432 Database/Table name limited to 64 bytes, not chars, problems with multi-byte
increased buffers for user name & db
sql/sql_acl.cc:
Bug#20393 User name truncation in mysql client
Bug#21432 Database/Table name limited to 64 bytes, not chars, problems with multi-byte
check that user name is not longer than USERNAME_LENGTH symbols
sql/sql_parse.cc:
Bug#20393 User name truncation in mysql client
Bug#21432 Database/Table name limited to 64 bytes, not chars, problems with multi-byte
increased buffers for user name & db
sql/table.cc:
Bug#20393 User name truncation in mysql client
Bug#21432 Database/Table name limited to 64 bytes, not chars, problems with multi-byte
check that db name is not longer than NAME_LEN symbols
mysql-test/lib/mtr_cases.pl:
Detect which tests that need ndb
mysql-test/lib/mtr_match.pl:
Add function mtr_match_substring
mysql-test/mysql-test-run.pl:
Only start cluster for test cases that need it
Default is "var/tmp"
mysql-test/r/myisam.result:
Update result file
mysql-test/t/myisam.test:
If running test suite with a non standard tmp dir, the "show create table" will print "DATA DIRECTORY="
Use replace_result to mask it out
Set tmpdir to var/log to get the printout of DATA DIRECTORY also when running with standard tmpdir
Must not use Item_direct_ref in HAVING because it points to
the new value (witch is not yet calculated for the first row).
mysql-test/r/subselect.result:
Bug #16255: Subquery in where
- test case
mysql-test/t/subselect.test:
Bug #16255: Subquery in where
- test case
sql/item_subselect.cc:
Bug #16255: Subquery in where
Must not use Item_direct_ref in HAVING because it points to
the new value (witch is not yet calculated for the first row).
