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: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: emre@hasegeli.com, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>, Thomas Munro <thomas.munro@enterprisedb.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2018-08-17T21:23:09Z
Lists: pgsql-hackers 
Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
> Hmm, yeah. Based on past experience, the powerpc machines are likely to
> stumble on this.

> FWIW my understanding is that these failures actually happen in new
> tests, it's not an issue introduced by this patch series.

Yeah, we've definitely hit such problems before.  The geometric logic
seems particularly prone to it because it's doing more and subtler
float arithmetic than the rest of the system ... but it's not the sole
source of minus-zero issues.

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