Horton

Re: power() function in Windows: "value out of range: underflow"

David Rowley <david.rowley@2ndquadrant.com>

View thread View on postgr.es
From: David Rowley <david.rowley@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Huong Dangminh <huo-dangminh@ys.jp.nec.com>, Pg Hackers <pgsql-hackers@postgresql.org>, Akio Iwaasa <aki-iwaasa@vt.jp.nec.com>
Date: 2018-04-29T23:24:28Z
Lists: pgsql-bugs, pgsql-hackers 
On 30 April 2018 at 10:22, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> David Rowley <david.rowley@2ndquadrant.com> writes:
>> Wouldn't this machine have returned 1 before this patch though?
>
> No, don't think so, because it doesn't set EDOM for the case.
>
> Basically what we're doing here is making sure that we get results
> conforming to current POSIX even on machines that predate that
> standard.  There are more of them floating around than I'd have
> expected, but it still seems like a good change to make.  Maybe
> there's an argument for not back-patching, though?

I think we should back patch and try to be consistent about the
power(float8 1.0, 'NaN') and power('NaN', float8 0.0) cases. The
archives don't show any complaints about power() with NaN until this
one, so I imagine the number of people affected by this is small.
However, I think if we're willing to try to make MSVC consistent with
other platforms on this topic then there's no reason to draw the line
there and ignore other platforms that we claim to support.

POSIX seems like a good standard to follow for this in the absence of
guidance from the SQL standard.

-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Commits

  1. Revert back-branch changes in power()'s behavior for NaN inputs.

  2. Avoid wrong results for power() with NaN input on more platforms.

  3. Avoid wrong results for power() with NaN input on some platforms.