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.
ps-modify1 used the user variables @1, @2, @100 set within ps_query and
ps_modify. That architecture was wrong, because the dependence
of ps_modify1 on ps_query and ps_modify makes the test script
maintenance and the use of these test cases during bug fixing/
debugging of single sub test cases very uncomfortable.
Therefore these user variables (@1, @2, @100) are also set within ps-modify1.
The result files of the test cases ps_2myisam, ps_3innodb, ps_4heap, ps_6bdb,
ps_7ndb will be affected by that change and show 3 additional lines, but
nothing else will change.
mysql-test/include/ps_modify1.inc:
Initialization of three user variables, with values derived from ps_query
and ps_modify
mysql-test/r/ps_2myisam.result:
updated result set
mysql-test/r/ps_3innodb.result:
updated result set
mysql-test/r/ps_4heap.result:
updated result sset
mysql-test/r/ps_6bdb.result:
updated result set
mysql-test/r/ps_7ndb.result:
updated result set
