Re: BUG #15925: Loss of precision converting money to numeric
Slawomir Chodnicki <slawomir.chodnicki@gmail.com>
From: Slawomir Chodnicki <slawomir.chodnicki@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-bugs@lists.postgresql.org
Date: 2019-07-26T16:15:00Z
Lists: pgsql-bugs
> Hmm, yeah, anything approaching INT64_MAX has a problem. > The issue is that cash_numeric() does the equivalent of > > SELECT 9223372036854775807::numeric / 100::numeric; > > and if you try that by hand you indeed get > > 92233720368547758 > > because select_div_scale() has decided that it need not produce > any fractional digits. We can force its hand by making the input > have the required number of fractional digits *before* dividing, > which is a bit weird on its face but gets the job done, per the > comment therein: > > * The result scale of a division isn't specified in any SQL standard. For > * PostgreSQL we select a result scale that will give at least > * NUMERIC_MIN_SIG_DIGITS significant digits, so that numeric gives a > * result no less accurate than float8; but use a scale not less than > * either input's display scale. > > (NUMERIC_MIN_SIG_DIGITS is 16, whence the problem for a 17-digit result. > Maybe we should consider raising that, but I'm hesitant to consider such > a far-reaching change just to make cash_numeric happy.) > > I intend to apply the attached patch. Thanks Tom, the response is illuminating. And a same-day patch is legendary. Thank you for your work. Slawo
Commits
-
Fix loss of fractional digits for large values in cash_numeric().
- fa854112fc3d 10.10 landed
- ca918f99aaa5 11.5 landed
- b9d2c5c7ac80 13.0 landed
- 81b29c87114c 9.4.24 landed
- 30bed9f63823 9.6.15 landed
- 13e493cf68a4 9.5.19 landed
- 01e0538e8b12 12.0 landed