On 30 April 2018 at 09:19, Tom Lane <t...@sss.pgh.pa.us> wrote: > http://netbsd.gw.com/cgi-bin/man-cgi?pow+3+NetBSD-5.2.3 > > which goes to great lengths to justify NaN^0 = 1 while saying nothing > to suggest that 1^NaN might not yield NaN. > > I'm not sure if we should add more special-case code for that, or just > remove that test case again. Historically we've not really felt that it > was our job to mask oddities of the platform's math library, so the fact > that power() is worrying about this seems like unjustified scope creep. > On the other hand, we do have a bunch of special cases there already, > so refusing to handle older BSD would be a tad inconsistent.
(Sorry missed your reply before I sent my last one) Wouldn't this machine have returned 1 before this patch though? Surely changing this behaviour this plaetform in favour of fixing on another is worse than doing nothing. If that's the case, I think the only option is to add a special case or revert this and document that the behaviour may vary depending on the platform's implementation of pow(). I think the special case is worth it, since there's already some for the error cases. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services