Re: Floating point comparison inconsistencies of the geometric types

On Wed, Sep 28, 2016 at 12:02 PM, Emre Hasegeli <emre(at)hasegeli(dot)com> wrote:

>> `make check` finds differences per the attached. Please
>> investigate why the regression tests are failing and what the
>> appropriate response is.
>
> I fixed the first one and workaround the second with COLLATE "C". I
> have how my changes caused this regression.
>
> "select_views" test runs "SELECT name, #thepath FROM iexit ORDER BY 1,
> 2" and expects to get rows in this order:
>
>> I- 580 Ramp | 8
>> I- 580/I-680 Ramp | 2
>
> With the collation on my laptop, this is actually true:
>
>> regression=# select 'I- 580/I-680 Ramp' < 'I- 580 Ramp';
>> ?column?
>> ----------
>> t
>> (1 row)
>
> However, on the Linux server, I am testing it is not:
>
>> regression=# select 'I- 580 Ramp' < 'I- 580/I-680 Ramp';
>> ?column?
>> ----------
>> f
>> (1 row)
>
> Do you know how it is not failing on the master?

Well, those two results are not contradictory -- notice that you
switched the order of the values in the comparison. I don't think
you've really found the explanation yet.

>> [discussing inline static functions compared to macros for min()/max(), etc.]
>> I suspect that they will be as fast or faster, and they eliminate
>> the hazard of multiple evaluation, where a programmer might not be
>> aware of the multiple evaluation or of some side-effect of an
>> argument.
>
> I reworked the the patches to use inline functions and fixed the
> problems I found. The new versions are attached.

Will take a look and post again.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company