Re: Floating point comparison inconsistencies of the geometric types - Mailing list pgsql-hackers

From Emre Hasegeli
Subject Re: Floating point comparison inconsistencies of the geometric types
Date
Msg-id CAE2gYzwZf7F7XO=_oPhdcpR0YGDdqwQEeB6Z=Xbxowp8q1-saw@mail.gmail.com
Whole thread Raw
In response to Re: Floating point comparison inconsistencies of the geometric types  (Kevin Grittner <kgrittn@gmail.com>)
Responses Re: Floating point comparison inconsistencies of the geometric types
List pgsql-hackers
> These patches apply and build on top of 5c609a74 with no problems,
> but `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?

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

Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [PATCH] SortSupport for macaddr type
Next
From: Robert Haas
Date:
Subject: Re: Binary I/O for isn extension