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):

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

        [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:

Reply via email to