Horton

Re: [PATCH] Improve geometric types

Thomas Munro <thomas.munro@enterprisedb.com>

View thread View on postgr.es
From: Thomas Munro <thomas.munro@enterprisedb.com>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>, Emre Hasegeli <emre@hasegeli.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2018-07-29T10:57:57Z
Lists: pgsql-hackers 
On Sun, Jul 29, 2018 at 10:35 PM, Tomas Vondra
<tomas.vondra@2ndquadrant.com> wrote:
> It's always 0/-0 difference, and it's limited to power machines. I'll
> try to get access to such system and see what's wrong.

This is suspicious:

        /* on some platforms, the preceding expression tends to produce -0 */
        if (line->C == 0.0)
            line->C = 0.0;

FWIW I tried this on our Linux/POWER8 box but it didn't show the problem.

-- 
Thomas Munro
http://www.enterprisedb.com

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