From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Christoph Berg <christoph(dot)berg(at)credativ(dot)de> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: extra_float_digits and casting from real to numeric |
Date: | 2014-01-07 16:43:18 |
Message-ID: | 14979.1389112998@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Christoph Berg <christoph(dot)berg(at)credativ(dot)de> writes:
> A customer recently upgraded their jdbc driver from 8.4 to 9.2. This
> enabled the binary wire protocol (effectively between 9.1 and 9.2).
> They reported that single precision values inserted into a
> numeric(10,2) column were suddenly rounded wrongly, i.e. 10000.18 was
> inserted as 10000.20, while that worked before. Of course we told them
> that single is the wrong data type for this, but still, this is a
> regression.
I'm not sure that it's fair to characterize that as a regression.
If anything, it's more sensible than what happened before.
> 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 think your customer got bit by his own bad coding practice, and
that should be the end of it.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2014-01-07 16:43:51 | Re: Assertion failure in base backup code path |
Previous Message | Magnus Hagander | 2014-01-07 16:40:07 | Re: Assertion failure in base backup code path |