Emre Hasegeli <e...@hasegeli.com> writes: >> Uh, I thought pg_hypot() was still needed on our oldest supported >> platforms. Or is hypot() already supported there?
> What is our oldest supported platform? Our normal reference for such questions is SUS v2 (POSIX 1997): http://pubs.opengroup.org/onlinepubs/007908799/ I looked into that, and noted that it does specify hypot(), but it has different rules for edge conditions: If the result would cause overflow, HUGE_VAL is returned and errno may be set to [ERANGE]. If x or y is NaN, NaN is returned. and errno may be set to [EDOM]. If the correct result would cause underflow, 0 is returned and errno may be set to [ERANGE]. whereas POSIX 2008 saith: If the correct value would cause overflow, a range error shall occur and hypot(), hypotf(), and hypotl() shall return the value of the macro HUGE_VAL, HUGE_VALF, and HUGE_VALL, respectively. [MX] If x or y is ±Inf, +Inf shall be returned (even if one of x or y is NaN). If x or y is NaN, and the other is not ±Inf, a NaN shall be returned. [MXX] If both arguments are subnormal and the correct result is subnormal, a range error may occur and the correct result shall be returned. In short, the reason that the existing comment makes a point of the Inf-and-NaN behavior is that the standard changed somewhere along the line. While I believe we could get away with assuming that hypot() exists everywhere, it's much less clear that we could rely on the result being Inf and not NaN in this case. Now, it's also not clear that anything in PG really cares. But if we do care, I think we should keep pg_hypot() ... and maybe clarify the comment a bit more. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
