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
-
Improve test coverage of geometric types
- a3d2844852dc 12.0 landed
-
Fix problems in handling the line data type
- 2e2a392de391 12.0 landed
-
Use the built-in float datatypes to implement geometric types
- c4c340088546 12.0 landed
-
Remove remaining GEODEBUG references from geo_ops.c
- a082aed0723c 12.0 landed
-
Provide separate header file for built-in float types
- 6bf0bc842bd7 12.0 landed
-
Refactor geometric functions and operators
- a7dc63d904a6 12.0 landed
-
Fix crash in close_ps() for NaN input coordinates.
- 278148907a97 9.6.0 cited
-
Fix GiST index build for NaN values in geometric types.
- 1acf75725545 9.6.0 cited
-
Enable building with Visual Studion 2013.
- cec8394b5ccd 9.4.0 cited
-
Suppress -0 in the C field of lines computed by line_construct_pts().
- 43fe90f66a0b 9.4.0 cited