Output TIMESTAMP in 4.1 format for 4.1 tables (or for TIMESTAMP(19)) (portability fix)
Fixed that INTERVAL can handle big integers. (Bug #3498)
Fixed that hostname="" works identical as hostname="%" for table/column grants (Bug #3473)
Item_func_from_days::get_date didn't change 'hr', 'min' and some
other fields of incoming ltime, so they got random values.
bzeroing of the ltime added
Fixed problem with char > 128 in QUOTE() function. (Bug #1868)
Disable creation of symlinks if my_disable_symlink is set
Fixed searching of TEXT with end space. (Bug #1651)
Fixed caching bug in multi-table-update where same table was used twice. (Bug #1711)
Fixed problem with UNIX_TIMESTAMP() for timestamps close to 0. (Bug #1998)
Fixed timestamp.test
New formats added for 'week()' function and 'default_week_format' option(4 - 7).
Next formats is supported now:
*Value* *Meaning*
`0' Week starts on Sunday; First Sunday of the year starts week 1.
Week() returns 0-53.
`1' Week starts on Monday; Weeks numbered according to ISO 8601:1988.
Week() returns 0-53.
`2' Week starts on Sunday; First Sunday of the year starts week 1.
Week() returns 1-53.
`3' Week starts on Monday; Weeks numbered according to ISO 8601:1988.
Week() returns 1-53.
`4' Week starts on Sunday; Weeks numbered according to ISO 8601:1988.
Week() returns 0-53.
`5' Week starts on Monday; First Monday of the year starts week 1.
Week() returns 0-53.
`6' Week starts on Sunday; Weeks numbered according to ISO 8601:1988.
Week() returns 1-53.
`7' Week starts on Monday; First Monday of the year starts week 1.
Week() returns 1-53.
Changed timestamp to return string in YYYY-MM-DD HH:MM:SS format.
DATE_ADD() and related functions now returns correct DATE/DATETIME type depending on argument types.
Now all tests passes, still some work left to remove warnings in log files from mysql-test-run
do val_int() on their arguments before starting the computation.
Similar fixes are need for +-* and probably several other but I want
to make sure Monty is fine with my fix approach before changing a lot
of code.
Amazingly,
this bug is not as critical as you would expect since very few functions do val_int()
on their arguments ( from_unixtime(), sec_to_time()), and those not
very frequently perform a computation on their floating point arguments.
which is probably why no one has yet reported this bug. Another
possibility is that the result is usually wrong by no more than 5%,
which makes it hard to catch it. I found it when trying to compute mile
splits for 30:47 10K - it told me 5:07, and I knew it was wrong because
5:00 mile gives you 31:08. However, if I had not run as many 10K races,
I would have easily believed that 30:47 10K is a 5:07 mile pace and
would not have noticed the bug.
Allow delete of crashed MyISAM tables
Fixed bug when BLOB was first part of key
Fixed bug when using result from CASE in GROUP BY
Fixed core-dump bug in monthname()
Optimized calling of check_db_name()
