Re: [HACKERS] [PATCH] Improve geometric types

Emre Hasegeli <emre@hasegeli.com>

From: Emre Hasegeli <emre@hasegeli.com>
To: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Álvaro Herrera <alvherre@alvh.no-ip.org>, Robert Haas <robertmhaas@gmail.com>, Aleksander Alekseev <a.alekseev@postgrespro.ru>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2018-02-07T15:46:38Z
Lists: pgsql-hackers
>  - line_eq looks too complex in the normal (not containing NANs)
>    cases.  We should avoid such complexity if possible.
>
>    One problem here is that comparison conceals NANness of
>    operands. Conversely arithmetics propagate it. We can converge
>    NANness into a number. The attached line_eq() doesn that. This
>    doesn't have almost no additional complexity when NAN is
>    involved. I believe it qbehaves in the same way
>    and shares a doubious behavior like this.
>
>    =# select '{nan, 1, nan}'::line = '{nan, 2, nan}'::line;
>     ?column?
>    ----------
>     t
>
>    But probably no point in fixing(?) it.

I think we should fix it.

>    The attached file contains line_eq, point_eq_point and
>    circle_same. I expect that line_eq is fast but other two are
>    doubious.

I haven't got an attachment.

>    . . . Mmm.. The function seems broken. I posted the fix for
>    the existing version is posted, and line_perp() in the attched
>    file will work fine.

I am incorporating the fix you have posted to the other thread to this patch.


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().