maria-developers team mailing list archive

[Sergei Golubchik <serg@xxxxxxxxxxx>]

Hi, Alexander!

> I removed find_num_type() and fix_num_length_and_dec() which
> were hard to track, and for some Items these methods were
> erroneously called twice.
> 
> fix_num_length_and_dec() now only exists as a non-virtual method in
> Item_sum and Item_udf_func.

Why did you keep them?

> === modified file 'sql/item_func.cc'
> --- sql/item_func.cc	2014-06-04 16:32:57 +0000
> +++ sql/item_func.cc	2014-06-09 07:58:55 +0000
> @@ -1618,8 +1606,20 @@ my_decimal *Item_func_div::decimal_op(my
>  
>  void Item_func_div::result_precision()
>  {
> +  /*
> +    We need to add args[1]->divisor_precision_increment(),
> +    to properly handle the cases like this:
> +      SELECT 5.05 / 0.014; -> 360.714286
> +    i.e. when the divisor has a zero integer part
> +    and non-zero digits appear only after the decimal point.
> +    Precision in this example is calculated as
> +      args[0]->decimal_precision()           +  // 3
> +      args[1]->divisor_precision_increment() +  // 3
> +      prec_increment                            // 4
> +    which gives 10 decimals digits. 
> +  */
>    uint precision=min(args[0]->decimal_precision() + 
> -                     args[1]->decimals + prec_increment,
> +                     args[1]->divisor_precision_increment() + prec_increment,

I don't understand that, why divisor_precision_increment() and not
decimals (or decimal_scale()) ?

>                       DECIMAL_MAX_PRECISION);
>  
>    /* Integer operations keep unsigned_flag if one of arguments is unsigned */

Regards,
Sergei