Re: pgsql: Fix behavior of exp() and power() for infinity inputs.

Michael Paquier <michael@paquier.xyz> writes:
> On Mon, Jun 15, 2020 at 12:10:52AM -0400, Tom Lane wrote:
>> Yeah, and presumably Noah's other AIX critters will fail too.  I'm curious
>> to see what damselfly will say; that's the other old-ish platform we have
>> in the farm.  Once that reports in, I'm intending to push the attached or
>> something close to it.  This is more or less the same thing for pow() as
>> the current patch did for exp(): handle Inf cases manually and then
>> simplify the error checks in the normal path.

For the record, damselfly did indeed fail:

https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=damselfly&dt=2020-06-15%2011%3A23%3A34

So while it's pretty debatable whether we should care about obsolete
NetBSD or HPUX versions, we do have an issue on both AIX and Illumos,
which seems like sufficient reason to add the manual infinity handling.

> Thanks.  What you have here looks consistent with what POSIX says:
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/pow.html

Right, it's based directly on the POSIX rules.

One thing worth noting is that I changed what the code does if pow()
returns EDOM.  That's probably a dead code path on any modern platform,
given that we already checked for invalid input.  But if it did occur
I think we should raise the same "domain error" message we use up top.
There are two objections to the way the code stands:

1. It's effectively computing the result as though y is infinity,
which (after the inf additions I propose here) we know isn't so.
I think it makes more sense to decide "y isn't an integer even
though we thought it was" than "y is infinite even though we thought
it wasn't".  Integer-ness, for float values too large to have any
fractional bits, is a squishy concept, but infinite-ness isn't.

2. If we did want to conclude y is infinite, we should be prepared to
return inf or 0 on that basis.  What actually happens, given the following
error checks, is either an underflow error, an overflow error, or
returning 1.0.  I don't think any of those is a sensible way of reporting
EDOM.

When that stanza of code was written, we had *none* of the special case
checks that are now done before invoking pow(), so it had to consider a
wider range of possibilities than it now does.  I'm a little dubious that
it was OK even then, but it's definitely off the mark now.

            regards, tom lane