David Rowley <david.rowley@2ndquadrant.com> writes:
> You patch fixes the problem for me, and importantly the two following
> cases still work:
> postgres=# select power(1,'NaN');
> power
> -------
> 1
> (1 row)
> postgres=# select power('NaN', 0);
> power
> -------
> 1
> (1 row)
> There's no mention in the SQL standard about NaN handling in the above
> two cases, but I wonder if it's worth also adding a couple of tests
> for the above two cases to ensure all platforms are doing the same
> thing... ?
So the early returns from the buildfarm say "no, they aren't". It looks
like older BSDen know the NaN^0 = 1 rule, but they return NaN for 1^NaN.
Aside from the failure buildfarm member nightjar is showing, I've
confirmed this behavior on a NetBSD 5.2 installation I had laying around,
and there's also evidence in the related man page:
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.
And, while we're on the subject ... some of my machines give
postgres=# select power(-1,'NaN');
ERROR: a negative number raised to a non-integer power yields a complex result
POSIX says this should return NaN, not an error (and my old NetBSD
installation does that, as does numeric_power). Should we change it?
I'm a bit inclined to handle all the NaN-input cases with explicit
code before we do anything that relies on libc's behavior.
BTW, numeric_power just emits NaN for NaN input, without either of
these special cases. But that's platform-independent, so I'm hesitant
to consider back-patching a change there; if we change that, I'd vote
for doing so only in HEAD.
regards, tom lane