From: | Slawomir Chodnicki <slawomir(dot)chodnicki(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #15925: Loss of precision converting money to numeric |
Date: | 2019-07-26 16:15:00 |
Message-ID: | A6E2C5F9-7437-41B1-9F18-4E6C35981F6B@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2019-07-26 18:11:08 | BUG #15927: PGresult *PQexecParams(..) not work on view |
Previous Message | Tom Lane | 2019-07-26 15:17:34 | Re: BUG #15925: Loss of precision converting money to numeric |