database/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-07-27 18:02:13 +03:00
Code Activity

MDEV-17351 Wrong results for GREATEST,TIMESTAMP,ADDTIME with an out-of-range TIME-alike argument

Browse Source 
Problems:

Functions LEAST() and GREATEST() in TIME context, as well as functions
TIMESTAMP(a,b) and ADDTIME(a,b), returned confusing results when the
input TIME-alike value in a number or in a string was out of the TIME
supported range.

In case of TIMESTAMP(a,b) and ADDTIME(a,b), the second argument
value could get extra unexpected digits. For example, in:
    ADDTIME('2001-01-01 00:00:00', 10000000)  or
    ADDTIME('2001-01-01 00:00:00', '1000:00:00')
the second argument was converted to '838:59:59.999999'
with six fractional digits, which contradicted "decimals"
previously set to 0 in fix_length_and_dec().
These unexpected fractional digits led to confusing function results.

Changes:
1. GREATEST(), LEAST()

   - fixing Item_func_min_max::get_time_native()
   to respect "decimals" set by fix_length_and_dec().
   If a value of some numeric or string time-alike argument
   goes outside of the TIME range and gets limited to '838:59:59.999999',
   it's now right-truncated to the correct fractional precision.

   - fixing, Type_handler_temporal_result::Item_func_min_max_fix_attributes()
   to take into account arguments' time_precision() or datetime_precision(),
   rather than rely on "decimals" calculated by the generic implementation
   in Type_handler::Item_func_min_max_fix_attributes(). This makes
   GREATEST() and LEAST() return better data types, with the same
   fractional precision with what TIMESTAMP(a,b) and ADDTIME(a,b) return
   for the same arguments, and with DATE(a) and TIMESTAMP(a).

2. Item_func_add_time and Item_func_timestamp

   It was semantically wrong to apply the limit of the TIME data type
   to the argument "b", which plays the role of "INTERVAL DAY TO SECOND" here.
   Changing the code to fetch the argument "b" as INTERVAL rather than as TIME.

   The low level routine calc_time_diff() now gets the interval
   value without limiting to '838:59:59.999999', so in these examples:
     ADDTIME('2001-01-01 00:00:00', 10000000)
     ADDTIME('2001-01-01 00:00:00', '1000:00:00')
   calc_time_diff() gets '1000:00:00' as is.  The SQL function result
   now gets limited to the supported result data type range
   (datetime or time) inside calc_time_diff(), which now calculates
   the return value using the real fractional digits that
   came directly from the arguments (without the effect of limiting
   to the TIME range), so the result does not have any unexpected
   fractional digits any more.

   Detailed changes in TIMESTAMP() and ADDTIME():

   - Adding a new class Interval_DDhhmmssff. It's similar to Time, but:
     * does not try to parse datetime format, as it's not needed for
       functions TIMESTAMP() and ADDTIME().
     * does not cut values to '838:59:59.999999'

     The maximum supported Interval_DDhhmmssff's hard limit is
     'UINT_MAX32:59:59.999999'. The maximum used soft limit is:
     - '87649415:59:59.999999'   (in 'hh:mm:ss.ff' format)
     - '3652058 23:59:59.999999' (in 'DD hh:mm:ss.ff' format)
     which is a difference between:
     - TIMESTAMP'0001-01-01 00:00:00' and
     - TIMESTAMP'9999-12-31 23:59:59.999999'
     (the minimum datetime that supports arithmetic, and the
     maximum possible datetime value).

   - Fixing get_date() methods in the classes related to functions
     ADDTIME(a,b) and TIMESTAMP(a,b) to use the new class Interval_DDhhmmssff
     for fetching data from the second argument, instead of get_date().

   - Fixing fix_length_and_dec() methods in the classes related
     to functions ADDTIME(a,b) and TIMESTAMP(a,b) to use
     Interval_DDhhmmssff::fsp(item) instead of item->time_precision()
     to get the fractional precision of the second argument correctly.

   - Splitting the low level function str_to_time() into smaller pieces
     to reuse the code. Adding a new function str_to_DDhhmmssff(), to
     parse "INTERVAL DAY TO SECOND" values.

   After these changes, functions TIMESTAMP() and ADDTIME()
   return much more predictable results, in terms of fractional
   digits, and in terms of the overall result.

   The full ranges of DATETIME and TIME values are now covered by TIMESTAMP()
   and ADDTIME(), so the following can now be calculated:

    SELECT ADDTIME(TIMESTAMP'0001-01-01 00:00:00', '87649415:59:59.999999');
    -> '9999-12-31 23:59:59.999999'

    SELECT TIMESTAMP(DATE'0001-01-01', '87649415:59:59.999999')
    -> '9999-12-31 23:59:59.999999'

    SELECT ADDTIME(TIME'-838:59:59.999999', '1677:59:59.999998');
    -> '838:59:59.999999'
This commit is contained in:
Alexander Barkov
2018-10-08 13:38:01 +04:00
parent d03581bf3c
commit b639fe2be1
14 changed files with 3494 additions and 77 deletions
Download Patch File Download Diff File Expand all files Collapse all files

82
sql/sql_type.h
View File

@ -446,6 +446,7 @@ public:
class Temporal: protected MYSQL_TIME
{
public:
static date_mode_t sql_mode_for_dates(THD *thd);
bool is_valid_temporal() const
{
DBUG_ASSERT(time_type != MYSQL_TIMESTAMP_ERROR);
@ -469,6 +470,16 @@ protected:
CHARSET_INFO *cs, date_mode_t fuzzydate);
bool str_to_datetime(MYSQL_TIME_STATUS *st, const char *str, size_t length,
CHARSET_INFO *cs, date_mode_t fuzzydate);
bool has_valid_mmssff() const
{
return minute <= TIME_MAX_MINUTE &&
second <= TIME_MAX_SECOND &&
second_part <= TIME_MAX_SECOND_PART;
}
bool has_zero_YYYYMMDD() const
{
return year == 0 && month == 0 && day == 0;
}
public:
static void *operator new(size_t size, MYSQL_TIME *ltime) throw()
{
@ -492,8 +503,13 @@ public:
class Temporal_hybrid: public Temporal
{
public:
Temporal_hybrid(THD *thd, Item *item);
Temporal_hybrid(Item *item): Temporal_hybrid(current_thd, item) { }
Temporal_hybrid(THD *thd, Item *item, date_mode_t fuzzydate);
Temporal_hybrid(THD *thd, Item *item)
:Temporal_hybrid(thd, item, sql_mode_for_dates(thd))
{ }
Temporal_hybrid(Item *item)
:Temporal_hybrid(current_thd, item)
{ }
Temporal_hybrid(MYSQL_TIME_STATUS *st, const char *str, size_t length,
CHARSET_INFO *cs, date_mode_t fuzzydate)
{
@ -538,6 +554,63 @@ public:
};
class Interval_DDhhmmssff: public Temporal
{
static const LEX_CSTRING m_type_name;
bool str_to_DDhhmmssff(MYSQL_TIME_STATUS *status,
const char *str, size_t length, CHARSET_INFO *cs,
ulong max_hour);
void push_warning_wrong_or_truncated_value(THD *thd,
const ErrConv &str,
int warnings);
bool is_valid_interval_DDhhmmssff_slow() const
{
return time_type == MYSQL_TIMESTAMP_TIME &&
has_zero_YYYYMMDD() && has_valid_mmssff();
}
bool is_valid_value_slow() const
{
return time_type == MYSQL_TIMESTAMP_NONE ||
is_valid_interval_DDhhmmssff_slow();
}
public:
// Get fractional second precision from an Item
static uint fsp(THD *thd, Item *item);
/*
Maximum useful HOUR value:
TIMESTAMP'0001-01-01 00:00:00' + '87649415:59:59' = '9999-12-31 23:59:59'
This gives maximum possible interval values:
- '87649415:59:59.999999' (in 'hh:mm:ss.ff' format)
- '3652058 23:59:59.999999' (in 'DD hh:mm:ss.ff' format)
*/
static uint max_useful_hour()
{
return 87649415;
}
public:
Interval_DDhhmmssff(THD *thd, MYSQL_TIME_STATUS *st, bool push_warnings,
Item *item, ulong max_hour);
Interval_DDhhmmssff(THD *thd, Item *item)
{
MYSQL_TIME_STATUS st;
new(this) Interval_DDhhmmssff(thd, &st, true, item, max_useful_hour());
}
const MYSQL_TIME *get_mysql_time() const
{
DBUG_ASSERT(is_valid_interval_DDhhmmssff_slow());
return this;
}
bool is_valid_interval_DDhhmmssff() const
{
return time_type == MYSQL_TIMESTAMP_TIME;
}
bool is_valid_value() const
{
return time_type == MYSQL_TIMESTAMP_NONE || is_valid_interval_DDhhmmssff();
}
};
/**
Class Time is designed to store valid TIME values.
@ -609,10 +682,7 @@ private:
bool is_valid_time_slow() const
{
return time_type == MYSQL_TIMESTAMP_TIME &&
year == 0 && month == 0 && day == 0 &&
minute <= TIME_MAX_MINUTE &&
second <= TIME_MAX_SECOND &&
second_part <= TIME_MAX_SECOND_PART;
has_zero_YYYYMMDD() && has_valid_mmssff();
}
void hhmmssff_copy(const MYSQL_TIME *from)
{