Feedback-ID: ic6394509:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-566-g3812ddbbc-fm-20240627.001-g3812ddbb
MIME-Version: 1.0
Message-Id: <c65c7129-50c6-4850-872b-b561701f99bf@app.fastmail.com>
In-Reply-To: 
 <CAEZATCXB+rDTuMjhK5ZxcouufigSc-X4tGJCBTMpZ3n=xxQuhg@mail.gmail.com>
References: 
 <CAEZATCXB+rDTuMjhK5ZxcouufigSc-X4tGJCBTMpZ3n=xxQuhg@mail.gmail.com>
Date: Sun, 07 Jul 2024 16:22:48 +0200
From: "Joel Jacobson" <joel@compiler.org>
To: "Dean Rasheed" <dean.a.rasheed@gmail.com>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Incorrect results from numeric round() and trunc()
Content-Type: text/plain
Archived-At: <https://www.postgresql.org/message-id/c65c7129-50c6-4850-872b-b561701f99bf%40app.fastmail.com>
Precedence: bulk

On Sun, Jul 7, 2024, at 13:28, Dean Rasheed wrote:
> The numeric round() and trunc() functions clamp the scale argument to
> the range between +/- NUMERIC_MAX_RESULT_SCALE, which is +/- 2000.
> That's a long way short of the actual allowed range of type numeric,
> so they produce incorrect results when rounding/truncating more than
> 2000 digits before or after the decimal point. For example,
> round(1e-5000, 5000) returns 0 instead of 1e-5000.
>
> Attached is a patch fixing that, using the actual documented range of
> type numeric.
>
> I've also tidied up a bit by replacing all instances of SHRT_MAX with
> a new constant NUMERIC_WEIGHT_MAX, whose name more accurately
> describes the limit, as used in various other overflow checks.
>
> In doing so, I also noticed a comment in power_var() which claimed
> that ln_dweight could be as low as -SHRT_MAX (-32767), which is wrong.
> It can only be as small as -NUMERIC_DSCALE_MAX (-16383), though that
> doesn't affect the point being made in that comment.
>
> I'd like to treat this as a bug-fix and back-patch it, since the
> current behaviour is clearly broken.

Fix seems straightforward to me.
I agree it should be back-patched.

Regards,
Joel