From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
Cc: | pgsql-committers(at)lists(dot)postgresql(dot)org |
Subject: | Re: pgsql: Fix numeric_mul() overflow due to too many digits after decimal |
Date: | 2021-07-10 15:01:12 |
Message-ID: | 2387728.1625929272@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> writes:
> This fixes an overflow error when using the numeric * operator if the
> result has more than 16383 digits after the decimal point by rounding
> the result. Overflow errors should only occur if the result has too
> many digits *before* the decimal point.
I think this needs a bit more thought. Before, a case like
select 1e-16000 * 1e-16000;
produced
ERROR: value overflows numeric format
Now you get an exact zero (with a lot of trailing zeroes, but still
it's just zero). Doesn't that represent catastrophic loss of
precision?
In general, I'm disturbed that we just threw away the previous
promise that numeric multiplication results were exact. That
seems like a pretty fundamental property --- which is stated
in so many words in the manual, btw --- and I'm not sure I want
to give it up.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Dean Rasheed | 2021-07-10 17:03:54 | Re: pgsql: Fix numeric_mul() overflow due to too many digits after decimal |
Previous Message | Michael Paquier | 2021-07-10 12:49:14 | pgsql: Add more sanity checks in SASL exchanges |
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2021-07-10 15:47:12 | Re: proposal: possibility to read dumped table's name from file |
Previous Message | vignesh C | 2021-07-10 14:49:13 | Re: psql - factor out echo code |