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, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>, Thomas Munro <thomas.munro@enterprisedb.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2018-09-27T10:57:12Z
Lists: pgsql-hackers

On 09/27/2018 12:48 AM, Tom Lane wrote:
> Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
>> On 09/26/2018 06:45 PM, Tom Lane wrote:
>>> gaur's not happy, but rather surprisingly, it looks like we're
>>> mostly OK elsewhere.  Do you need me to trace down exactly what's
>>> going wrong on gaur?
> 
>> Or you could just try doing
>>      select '(0,0)'::point * '(-3,4)'::point;
>> If this is what's going on, I'd say the best solution is to make it
>> produce (0,0) everywhere, so that we don't expect -0.0 anywhere.
> 
> Actually, it seems simpler than that: gaur produces plus zero already
> from the multiplication:
> 
> regression=# select '-3'::float8 * '0'::float8;
>   ?column?
> ----------
>          0
> (1 row)
> 
> whereas I get -0 elsewhere.  I'm surprised that this doesn't create
> more widely-visible regression failures, but there you have it.
> 

Hmmm, interesting. But I still don't quite understand why the test 
program still produced -0.000000 and not 0.000000. That seems like a 
direct contradiction to what we see in regression tests, doesn't it?

>> We could do that either by adding the == 0.0 check to yet another place,
>> or to point_construct() directly. Adding it to point_construct() means
>> we'll pay the price always, but I guess there are few paths where we
>> know we don't need it. And if we add it to many places it's likely about
>> as expensive as adding it to point_construct.
> 
> If gaur is the only machine showing this failure, which seems more
> likely by the hour, I'm not sure that we should give up performance
> across-the-board to make it happy.  Perhaps a variant expected-file
> is a better answer; or we could remove these specific test cases.
> 
> Anyway, I'd counsel doing nothing for a day or so, till the buildfarm
> breakage from the strerror/snprintf changes clears up.  Then we'll
> have a better idea of whether any other machines are affected.
> 

Yep, gaur seems to be the only animal affected by this, so no need to 
rush anyway.

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