Re: pgsql: Fix numeric_mul() overflow due to too many digits after decimal - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pgsql: Fix numeric_mul() overflow due to too many digits after decimal
Date
Msg-id 2407772.1625938242@sss.pgh.pa.us
Whole thread Raw
Responses Re: pgsql: Fix numeric_mul() overflow due to too many digits after decimal  (Dean Rasheed <dean.a.rasheed@gmail.com>)
List pgsql-hackers
[ moving to pghackers for wider visibility ]

Dean Rasheed <dean.a.rasheed@gmail.com> writes:
> On Sat, 10 Jul 2021 at 16:01, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.

> Perhaps we should amend the statement about numeric multiplication to
> say that it's exact within the limits of the numeric type's supported
> scale, which we also document in the manual as 16383.
> That seems a lot better than throwing an overflow error for a result
> that isn't very big, which limits what's possible with numeric
> multiplication to much less than 16383 digits.

TBH, I don't agree.  I think this is strictly worse than what we
did before, and we should just revert it.  It's no longer possible
to reason about what numeric multiplication will do.  I think
throwing an error if we can't represent the result exactly is a
preferable behavior.  If you don't want exact results, use float8.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: [HACKERS] WIP aPatch: Pgbench Serialization and deadlock errors
Next
From: Jeff Davis
Date:
Subject: Re: [EXTERNAL] Re: Crash in record_type_typmod_compare