Horton

Re: [PATCH] Improve geometric types

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: emre@hasegeli.com
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>, Robert Haas <robertmhaas@gmail.com>, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>, Aleksander Alekseev <a.alekseev@postgrespro.ru>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2017-10-03T14:03:25Z
Lists: pgsql-hackers 
Emre Hasegeli <emre@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

Commits

  1. Improve test coverage of geometric types

  2. Fix problems in handling the line data type

  3. Use the built-in float datatypes to implement geometric types

  4. Remove remaining GEODEBUG references from geo_ops.c

  5. Provide separate header file for built-in float types

  6. Refactor geometric functions and operators

  7. Fix crash in close_ps() for NaN input coordinates.

  8. Fix GiST index build for NaN values in geometric types.

  9. Enable building with Visual Studion 2013.

  10. Suppress -0 in the C field of lines computed by line_construct_pts().