Re: Tom Lane 2014-01-07 <14979.1389112998@sss.pgh.pa.us>
> > But if extra_float_digits > 0 is set, I'd expect not only the float4
> > output to be affected by it, but also casts to other datatypes,
>
> This proposal scares me. extra_float_digits is strictly a matter of
> I/O representation, it does not affect any internal calculations.
> Moreover, since one of the fundamental attributes of type numeric
> is that it's supposed to give platform-independent results, I don't
> like the idea that you're likely to get platform-dependent results
> of conversions from float4/float8.
I forgot to mention one bit here, and that's actually what made me
think "wtf" and post here. The server log is of course also affected
by this, so you even get different parameters depending on
extra_float_digits, yet the numeric result is the same "bad" one:
2014-01-08 10:13:53 CET LOG: execute <unnamed>: INSERT INTO s VALUES($1)
2014-01-08 10:13:53 CET DETAIL: parameters: $1 = '10000.2'
2014-01-08 10:14:18 CET LOG: execute <unnamed>: INSERT INTO s VALUES($1)
2014-01-08 10:14:18 CET DETAIL: parameters: $1 = '10000.1797'
Of course this is all consistent and in practice sums up to "don't use
real/single"...
> I think your customer got bit by his own bad coding practice, and
> that should be the end of it.
What about this patch to mention this gotcha more explicitely in the
documentation?
diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml
new file mode 100644
index 0386330..968f4a7
*** a/doc/src/sgml/datatype.sgml
--- b/doc/src/sgml/datatype.sgml
*************** NUMERIC
*** 689,694 ****
--- 689,697 ---- <literal>0</literal>, the output is the same on every platform supported by PostgreSQL.
Increasingit will produce output that more accurately represents the stored value, but may be unportable.
+ Casts to other numeric datatypes and the <literal>to_char</literal>
+ function are not affected by this setting, it affects only the text
+ representation. </para> </note>
Christoph
--
cb@df7cb.de | http://www.df7cb.de/
