Re: [PATCH] Improve geometric types

Tomas Vondra <tomas.vondra@2ndquadrant.com>

From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: emre@hasegeli.com, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
Date: 2018-06-03T22:53:19Z
Lists: pgsql-hackers
On 06/03/2018 11:50 PM, Tom Lane wrote:
> Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
>> The main remaining question I have is what do do with back-branches.
>> Shall we back-patch this or not?
> 
> Given the behavioral changes involved, I'd say "no way".  That's
> reinforced by the lack of field complaints; if there were lots of
> complaints, maybe we'd be willing to break backwards compatibility,
> but ...
> 

Fair enough, I tend to over-estimate importance of bugfixes and 
under-estimate breakage due to behavior change. But if we don't want to 
back-patch this, I'm fine with that. I was a bit worried about making 
future backpatches more painful, but this code received only ~20 commits 
over the past files, half of that due tot pgindent, so that seems to be 
a non-issue.

But now I'm wondering what does this mean for existing indexes? Doesn't 
this effectively mean those are unlikely to give meaningful responses 
(in the old or new semantics)?


regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


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