Hi, Davi!
I have few questions, see below:
On Jul 08, Davi Arnaut wrote:
> === modified file 'mysql-test/r/type_newdecimal.result'
> --- a/mysql-test/r/type_newdecimal.result 2009-07-03 10:36:04 +0000
> +++ b/mysql-test/r/type_newdecimal.result 2009-07-08 13:18:39 +0000
> @@ -1495,9 +1495,9 @@ CREATE TABLE t1 (a int DEFAULT NULL, b i
> INSERT INTO t1 VALUES (3,30), (1,10), (2,10);
> SELECT a+CAST(1 AS decimal(65,30)) AS aa, SUM(b) FROM t1 GROUP BY aa;
> aa SUM(b)
> -2.000000000000000000000000000000 10
> -3.000000000000000000000000000000 10
> -4.000000000000000000000000000000 30
> +2.00000000000000000000000000000 10
> +3.00000000000000000000000000000 10
> +4.00000000000000000000000000000 30
why ?
> SELECT a+CAST(1 AS decimal(65,31)) AS aa, SUM(b) FROM t1 GROUP BY aa;
> ERROR 42000: Too big scale 31 specified for column '1'. Maximum is 30.
> DROP TABLE t1;
> @@ -1595,7 +1595,7 @@ Warnings:
> Note 1265 Data truncated for column 'my_col' at row 1
> DESCRIBE t1;
> Field Type Null Key Default Extra
> -my_col decimal(65,30) NO 0.000000000000000000000000000000
> +my_col decimal(32,30) NO 0.000000000000000000000000000000
why ?
(I cannot check the query that caused that as these lines
don't exist in my 5.4 or 6.0 trees)
> SELECT my_col FROM t1;
> my_col
> 1.123456789123456789123456789123
> === modified file 'sql/item.cc'
> --- a/sql/item.cc 2009-07-03 10:43:54 +0000
> +++ b/sql/item.cc 2009-07-08 13:18:39 +0000
> @@ -437,15 +437,13 @@ Item::Item(THD *thd, Item *item):
>
> uint Item::decimal_precision() const
> {
> + uint precision= max_length;
> Item_result restype= result_type();
>
> if ((restype == DECIMAL_RESULT) || (restype == INT_RESULT))
> - {
> - uint prec=
> - my_decimal_length_to_precision(max_length, decimals, unsigned_flag);
> - return min(prec, DECIMAL_MAX_PRECISION);
> - }
> - return min(max_length, DECIMAL_MAX_PRECISION);
> + precision= my_decimal_length_to_precision(max_length, decimals, unsigned_flag);
> +
> + return precision;
why capping the precision here was incorrect ?
I mean, were there user-visible effect, like incorrect results ?
> }
>
>
> === modified file 'sql/item_func.cc'
> --- a/sql/item_func.cc 2009-07-03 10:36:04 +0000
> +++ b/sql/item_func.cc 2009-07-08 13:18:39 +0000
> @@ -452,45 +452,8 @@ Field *Item_func::tmp_table_field(TABLE
> return make_string_field(table);
> break;
> case DECIMAL_RESULT:
> - {
> - uint8 dec= decimals;
> - uint8 intg= decimal_precision() - dec;
> - uint32 len= max_length;
> -
> - /*
> - Trying to put too many digits overall in a DECIMAL(prec,dec)
> - will always throw a warning. We must limit dec to
> - DECIMAL_MAX_SCALE however to prevent an assert() later.
> - */
> -
> - if (dec > 0)
> - {
> - int overflow;
> -
> - dec= min(dec, DECIMAL_MAX_SCALE);
> -
> - /*
> - If the value still overflows the field with the corrected dec,
> - we'll throw out decimals rather than integers. This is still
> - bad and of course throws a truncation warning.
> - */
> -
> - const int required_length=
> - my_decimal_precision_to_length(intg + dec, dec,
> - unsigned_flag);
> -
> - overflow= required_length - len;
> -
> - if (overflow > 0)
> - dec= max(0, dec - overflow); // too long, discard fract
> - else
> - /* Corrected value fits. */
> - len= required_length;
> - }
> -
> - field= new Field_new_decimal(len, maybe_null, name, dec, unsigned_flag);
> + field= make_new_decimal_field();
> break;
This wasn't part of your first patch. I don't see where in the test case
you cover this change.
> - }
> case ROW_RESULT:
> default:
> // This case should never be chosen
> === modified file 'sql/my_decimal.h'
> --- a/sql/my_decimal.h 2009-07-03 10:36:04 +0000
> +++ b/sql/my_decimal.h 2009-07-08 13:18:39 +0000
> @@ -51,7 +51,6 @@ C_MODE_END
> */
> #define DECIMAL_MAX_PRECISION (DECIMAL_MAX_POSSIBLE_PRECISION - 8*2)
> #define DECIMAL_MAX_SCALE 30
> -#define DECIMAL_NOT_SPECIFIED 31
Oh, so it was unused ?
>
> /**
> maximum length of string representation (number of maximum decimal
>
Regards / Mit vielen Grüßen,
Sergei
--
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Sergei Golubchik <serg@stripped>
/ /|_/ / // /\ \/ /_/ / /__ Principal Software Engineer/Server Architect
/_/ /_/\_, /___/\___\_\___/ Sun Microsystems GmbH, HRB München 161028
<___/ Sonnenallee 1, 85551 Kirchheim-Heimstetten
Geschäftsführer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin Häring
