diff options
author | Alexander Barkov <bar@mariadb.com> | 2018-04-20 18:11:27 +0400 |
---|---|---|
committer | Alexander Barkov <bar@mariadb.com> | 2018-04-20 18:11:27 +0400 |
commit | 9aaf62d058801ed8226c20d4b4e638d34f1542ef (patch) | |
tree | 34827a984e4d3e8e770f6f1c4a4a05c222cb6916 /sql/item.cc | |
parent | 38c799c9a5e5aadd3f4df157a4151dd1f71d5bcb (diff) | |
download | mariadb-git-9aaf62d058801ed8226c20d4b4e638d34f1542ef.tar.gz |
MDEV-15926 MEDIUMINT returns wrong I_S attributes
Problem:
The logic in store_column_type() with a switch on field type was
hard to follow. The part for MEDIUMINT (MYSQL_TYPE_INT24) was not correct.
It erroneously calculated the precision of MEDIUMINT UNSIGNED
as 7 instead of 8.
A similar hard-to-follow switch doing some type specific calculations
resided in adjust_max_effective_column_length(). It was also wrong for
MEDIUMINT (reported as a separate issue in MDEV-15946).
Solution:
1. Introducing a new class Information_schema_numeric_attributes
2. Adding a new virtual method Field::information_schema_numeric_attributes()
3. Splitting the logic in store_column_type() into virtual
implementations of information_schema_numeric_attributes().
4. In order to avoid adding duplicate code for the integer data types,
adding a new virtual method Field_int::numeric_precision(),
which returns the number of digits.
Additional changes:
1. Adding the "const" qualifier to Field::max_display_length()
2. Moving the code from adjust_max_effective_column_length()
directly to Field::max_display_length().
There was no any sense to have two implementations:
- a set of wrong virtual implementations for Field_xxx::max_display_length()
- additional code in adjust_max_effective_column_length() fixing
bad results of Field_xxx::max_display_length()
This change is safe:
- The code using Field::max_display_length()
in field.cc, sql_show.cc, sql_type.cc is not affected.
- The code in rpl_utility.cc is also not affected.
See a new DBUG_ASSSERT and new comments explaining why.
In the new reduction, Field_xxx::max_display_length() returns
correct results for all integer types (except MEDIUMINT, see below).
Putting implementations of numeric_precision() and max_display_length()
near each other in field.h made the logic much clearer and thus
helped to reveal bad results for Field_medium::max_display_length(),
which returns 9 instead of 8 for signed MEDIUMINT fields.
This problem will be addressed separately (MDEV-15946).
Note, this change is also useful for pluggable data types (see MDEV-4912),
as now a user defined Field_xxx has a way to control what's returned
in INFORMATION_SCHEMA.COLUMNS.NUMERIC_PRECISION and
INFORMATION_SCHEMA.COLUMNS.NUMERIC_SCALE by implementing
a desired behavior in Field_xxx::information_schema_numeric_attributes().
Diffstat (limited to 'sql/item.cc')
-rw-r--r-- | sql/item.cc | 27 |
1 files changed, 0 insertions, 27 deletions
diff --git a/sql/item.cc b/sql/item.cc index 56af69be427..35c5ab8cc3d 100644 --- a/sql/item.cc +++ b/sql/item.cc @@ -3187,33 +3187,6 @@ inline static uint32 adjust_max_effective_column_length(Field *field_par, uint32 max_length) { uint32 new_max_length= field_par->max_display_length(); - uint32 sign_length= (field_par->flags & UNSIGNED_FLAG) ? 0 : 1; - - switch (field_par->type()) - { - case MYSQL_TYPE_INT24: - /* - Compensate for MAX_MEDIUMINT_WIDTH being 1 too long (8) - compared to the actual number of digits that can fit into - the column. - */ - new_max_length+= 1; - /* fall through */ - case MYSQL_TYPE_LONG: - case MYSQL_TYPE_TINY: - case MYSQL_TYPE_SHORT: - - /* Take out the sign and add a conditional sign */ - new_max_length= new_max_length - 1 + sign_length; - break; - - /* BINGINT is always 20 no matter the sign */ - case MYSQL_TYPE_LONGLONG: - /* make gcc happy */ - default: - break; - } - /* Adjust only if the actual precision based one is bigger than specified */ return new_max_length > max_length ? new_max_length : max_length; } |