mirror of
https://github.com/MariaDB/server.git
synced 2025-01-16 03:52:35 +01:00
368ac9f03e
MySQL officially supports DATE values starting from 1000-01-01. This is enforced for int values, but not for string values, thus one could easily insert '0001-01-01' value. Int values are checked by number_to_datetime function and Item_cache_datetime::val_str uses it to fill MYSQL_TIME struct out of cached int value. This leads to the scenario where Item_cache_datetime caches a non-null datetime value and when it tries to convert it from int to string number_to_datetime function treats the value as out-of-range and returns an error and Item_cache_datetime::val_str returns NULL for a non-null value. Due to this inconsistency server crashes. Now number_to_datetime allows DATE values below 1000-01-01 if the TIME_FUZZY_DATE flag is set. Better NULL handling for Item_cache_datetime. Added the Item_cache_datetime::store function to reset str_value_cached flag when an item is stored. mysql-test/r/type_date.result: Added a test case for the bug#57278. mysql-test/t/type_date.test: Added a test case for the bug#57278. sql-common/my_time.c: Bug#57278: Crash on min/max + with date out of range. Now number_to_datetime allows DATE values below 1000-01-01 if the TIME_FUZZY_DATE flag is set. sql/item.cc: Bug#57278: Crash on min/max + with date out of range. Item_cache_datetime::val_str now better handles null_value. |
||
---|---|---|
.. | ||
client.c | ||
client_plugin.c | ||
Makefile.am | ||
my_time.c | ||
my_user.c | ||
pack.c |