Re: pgsql: Fix numeric_mul() overflow due to too many digits after decimal

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

In response to

Responses

Browse pgsql-committers by date

  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

Browse pgsql-hackers by date

  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