to behave well on 5.0 tables (well now you can't use tables from 4.1
and 5.0 with 4.0 because former use utf8, but still it is nice to have
similar code in acl_init() and replace_user_table()).
This also will make such GRANTs working in 5.0 (they are broken now).
mysql-test/r/grant.result:
Added test for GRANT which manipulates user limits.
mysql-test/t/grant.test:
Added test for GRANT which manipulates user limits.
mysql-test/r/func_str.result:
A result for test case for the bug #7495 involving either LTRIM()
or TRIM() within QUOTE() function.
mysql-test/t/func_str.test:
A test case for the bug #7495 involving either LTRIM() or TRIM()
within QUOTE() function.
sql/item_strfunc.cc:
Changes for LTRIM() and TRIM() functions that aleviate the bug
entirely.
STR_TO_DATE() function if there is another format specifier after %f
in format string". Also small cleanup of STR_TO_DATE() implementation.
(After review version.)
mysql-test/r/date_formats.result:
Added test for small bug in STR_TO_DATE() implementation which caused
microseconds to be gobbled from string result of this function, if
there was another specifier after %f in format string.
mysql-test/t/date_formats.test:
Added test for small bug in STR_TO_DATE() implementation which caused
microseconds to be gobbled from string result of this function, if
there was another specifier after %f in format string.
sql/item_timefunc.cc:
Small cleanup of str_to_date() implementation.
Renamed check_result_type() to less ambigous get_date_time_result_type()
and made it static. Also added handling of %X,%x,%V,%v to this function.
Fixed small bug in it which caused microseconds to be gobbled if there
was some other specifiers after %f.
Cleaned up comments a bit.
mysql-test/r/update.result:
Auto merged
mysql-test/t/update.test:
Auto merged
sql/sql_select.cc:
Auto merged
mysql-test/mysql-test-run.sh:
Merge from 4.0
(back to behaviour of 4.1.7). Warning was not fatal: mysqldump continued. And the good thing is that it helped spot that starting from 4.1.7,
SHOW CREATE DATABASE failed (if --single-transaction and first db has non-empty InnoDB table and there is a second db) and thus mysqldump
produced CREATE DATABASE statements missing the CHARACTER SET clause. Removing the bug which was in the server, and the warning reporting in
mysqldump (compatibility with old servers).
client/mysqldump.c:
don't report errors as we deal almost gracefully with them (back to code of 4.1.7)
mysql-test/r/flush_block_commit.result:
result update
mysql-test/t/flush_block_commit.test:
let's verify that SHOW CREATE DATABASE succeeds even if connection has open transaction.
sql/sql_parse.cc:
There is no reason to forbid SHOW CREATE DATABASE if connection has an open transaction
For numeric constants we only need to add, since the parser doesn't produce
negative numbers.
For strings we only add (we actually could substract 1 if given string is a constant
and it has '-number' form but we're not doing that because
* we set max_length bigger then necessary in other cases as well.
* the current solution is simpler and safer (bigger max_length is better then cutting out)
mysql-test/r/func_concat.result:
Test for BUG#6825
mysql-test/r/metadata.result:
Ajusted results according to fix of bug BUG#6825:length(-1) = 2 , not 1
mysql-test/t/func_concat.test:
Test for BUG#6825
which Heikki fixed in 4.1.8 and 4.0.23. I verified that without Heikki's patch the test fails (7 gets inserted).
Test added to 4.1 because in testsuite of 4.0 it's impossible to start slave with InnoDB.
mysql-test/mysql-test-run.sh:
Backport an improvement from 4.1: If the tool is run with '--force', give a list of all test cases that failed at the end.
This is essential for automated analysis of the build logs file.
even with zero month and day" aka "Date decoding trouble"
Two digit year should be interpreted correctly as year in 20th or 21st
century even with zero month and day. Only exception should be zero date
'00-00-00' or '00-00-00 00:00:00'.
mysql-test/r/type_datetime.result:
Added test for bug #7297 "Two digit year should be interpreted correctly
even with zero month and day"
mysql-test/t/type_datetime.test:
Added test for bug #7297 "Two digit year should be interpreted correctly
even with zero month and day"
sql/time.cc:
str_to_TIME(): Two digit year should be interpreted correctly as year
in 20th or 21st century even with zero month and day. Only exception
should be zero date '00-00-00' or '00-00-00 00:00:00'.
