Re: MySQL function parameter types

Luuk <luuk_at_invalid.lan> writes:
>it says:
>FORMAT(X,D)
>Formats the number X to a format like '#,###,###.##', rounded to D
>decimal places, and returns the result as a string. If D is 0, the
>result has no decimal point or fractional part.
>what official explanation are you looking for, when just looking at this
>one function?

  One can observe that X above has more precision than DOUBLE:

SELECT FORMAT( 1.000000000000000000000000000001, 33 );

+------------------------------------------------+
| FORMAT( 1.000000000000000000000000000001, 33 ) |
+------------------------------------------------+
| 1.000000000000000000000000000001               |
+------------------------------------------------+

  So, X does not narrow the decimal value to DOUBLE.   X has a DECIMAL or a VARCHAR type.

  On the other hand,

SELECT EXP( 1.0000000000000001 ) = EXP( 1 );   gives true, which hints at the argument being passed   as DOUBLE, because the 1.0000000000000001 seems to be   represented as 1e0.

  The source code for »FORMAT« says:

String *Item_func_format::val_str_ascii(String *str) { ... dec= (int) args[1]->val_int();
  if (args[0]->result_type() == DECIMAL_RESULT ||   args[0]->result_type() == INT_RESULT) ...   else { double nr= args[0]->val_real(); ...  

  and the source code for »EXP« says:

double Item_func_exp::val_real()
{ double value= args[0]->val_real();

  . So, when we read the source code, we can guess:

EXP( DOUBLE x ) FORMAT( DECIMAL|INT|DOUBLE x, INT d )

  Now the programmer can learn from this that high-scale   decimal values will be rounded to double, when passed   to EXP, but not when passed to format, where they will   be preserved.

  Maybe, »open source« software also means: »We do not   have to be too precise in the manual, as one can always   look it up in the source code« ... Received on Sat Aug 29 2015 - 20:02:33 CEST