Re: [PATCH] Improve geometric types

Emre Hasegeli <emre(at)hasegeli(dot)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