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

From Kyotaro HORIGUCHI
Subject Re: Floating point comparison inconsistencies of the geometric types
Date
Msg-id 20161111.110421.122299480.horiguchi.kyotaro@lab.ntt.co.jp
Whole thread Raw
In response to Re: Floating point comparison inconsistencies of the geometric types  (Emre Hasegeli <emre@hasegeli.com>)
Responses Re: Floating point comparison inconsistencies of the geometric types
Re: Floating point comparison inconsistencies of the geometric types
List pgsql-hackers
Hello,

> > Returning to the issue, the following query should give you the
> > expected result.
> >
> > SELECT name, #thepath  FROM iexit ORDER BY name COLLATE "C", 2;
> 
> Yes, I have worked around it like this.  What I couldn't understand is
> how my patch can cause this regression.  How is it passes on master
> without COLLATE?

Ah, sorry, I understand that *you* added the COLLATE.  Revering
select_views.sql/out to master actually causes a regression error.

The reason for that is that you forgot to edit an alternative
exptect file, which matches for en_US locale.

But the test doesn't for collation and the only difference
between the alternative expect files comes from the difference of
collation for the query. "the workaround" seems to be the right
way to do it. I recommend rather to leave the workaroud as it is
and remove select_views_1.out from the "expected" directory.

Aside from that, I'd like to comment this patch on other points
later.

regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center





pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Shared memory estimation for postgres
Next
From: Michael Paquier
Date:
Subject: Re: Unlogged tables cleanup