Re: Some improvements to numeric sqrt() and ln()

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

In response to

Browse pgsql-hackers by date

  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