Re: Floating point comparison inconsistencies of the geometric types

Поиск
Список
Период
Сортировка
От Emre Hasegeli
Тема Re: Floating point comparison inconsistencies of the geometric types
Дата
Msg-id CAE2gYzxijWKwJ-ZPD--QHM+SxMd+vL_81_3Xt0spnCbsqFH=Ug@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Floating point comparison inconsistencies of the geometric types  (Kevin Grittner <kgrittn@gmail.com>)
Ответы Re: Floating point comparison inconsistencies of the geometric types  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Список 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 по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Renaming of pg_xlog and pg_clog
Следующее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: asynchronous and vectorized execution