Re: Floating point comparison inconsistencies of the geometric types
От | Kyotaro HORIGUCHI |
---|---|
Тема | Re: Floating point comparison inconsistencies of the geometric types |
Дата | |
Msg-id | 20161110.193306.264948447.horiguchi.kyotaro@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: Floating point comparison inconsistencies of the geometric types (Emre Hasegeli <emre@hasegeli.com>) |
Ответы |
Re: Floating point comparison inconsistencies of the
geometric types
|
Список | pgsql-hackers |
Hello, At Thu, 29 Sep 2016 10:37:30 +0200, Emre Hasegeli <emre@hasegeli.com> wrote in <CAE2gYzxijWKwJ-ZPD--QHM+SxMd+vL_81_3Xt0spnCbsqFH=Ug@mail.gmail.com> > > 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? Perhaps you ran the test under the environment LC_COLLATE (or LANG) of something other than C. The reson for the result is collation. The following returns expected result. =# select 'I- 580 Ramp' < ('I- 580/I-680 Ramp' COLLATE "C");?column? ----------t (1 row) For a reason I don't know, say, en_US locale behaves in an unintuitive way. regression=# select ' ' < ('/' COLLATE "en_US"), ' x' < ('/a' COLLATE "en_US");?column? | ?column? ----------+----------t | f (1 row) Returning to the issue, the following query should give you the expected result. SELECT name, #thepath FROM iexit ORDER BY name COLLATE "C", 2; regards, -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: