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: | David Steele <david(at)pgmasters(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Some improvements to numeric sqrt() and ln() |
Date: | 2020-03-19 18:43:55 |
Message-ID: | 6645.1584643435@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> writes:
> On Wed, 4 Mar 2020 at 14:41, David Steele <david(at)pgmasters(dot)net> wrote:
>> Are these improvements targeted at PG13 or PG14? This seems a pretty
>> big change for the last CF of PG13.
> Well of course that's not entirely up to me, but I was hoping to
> commit it for PG13.
> It's very well covered by a large number of regression tests in both
> numeric.sql and numeric_big.sql, since nearly anything that calls
> ln(), log() or pow() ends up going through sqrt_var(). Also, the
> changes are local to functions in numeric.c, which makes them easy to
> revert if something proves to be wrong.
FWIW, I agree that this is a reasonable thing to consider committing
for v13. It's not adding any new user-visible behavior, so there's
no definitional issues to quibble over, which is usually what I worry
about regretting after an overly-hasty commit. And it's only touching
a few functions in one file, so even if the patch is a bit long, the
complexity seems pretty well controlled.
I've not read the patch in detail so this isn't meant as a review,
but from a process standpoint I see no reason not to go forward.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Dilger | 2020-03-19 18:47:46 | Re: Adding missing object access hook invocations |
Previous Message | Andres Freund | 2020-03-19 18:39:28 | Re: pg_stat_progress_basebackup - progress reporting for pg_basebackup, in the server side |