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 CAE2gYzxijWKwJ-ZPD--QHM+SxMd+vL_81_3Xt0spnCbsqFH=Ug@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
> 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.

I am sorry I copy-pasted the wrong example:

"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                        Ramp' < 'I- 580/I-680                  Ramp';
>  ?column?
> ----------
>  t
> (1 row)

on the Linux server I am testing, it is not:

> regression=# select 'I- 580                        Ramp' < 'I- 580/I-680                  Ramp';
>  ?column?
> ----------
>  f
> (1 row)

The later should be the case on your environment as the test was also
failing for you.  This is not consistent with the expected test
result.  Do you know how this test can still pass on the master?



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Renaming of pg_xlog and pg_clog
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: asynchronous and vectorized execution