Re: [HACKERS] [PATCH] Improve geometric types

Поиск
Список
Период
Сортировка
От Emre Hasegeli
Тема Re: [HACKERS] [PATCH] Improve geometric types
Дата
Msg-id CAE2gYzyUArNR1YcQ3MkqT4y-RLJhZ+Yg=nh=bnFsT6KVXJmGHw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] [PATCH] Improve geometric types  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Ответы Re: [HACKERS] [PATCH] Improve geometric types
Список pgsql-hackers
>  - line_eq looks too complex in the normal (not containing NANs)
>    cases.  We should avoid such complexity if possible.
>
>    One problem here is that comparison conceals NANness of
>    operands. Conversely arithmetics propagate it. We can converge
>    NANness into a number. The attached line_eq() doesn that. This
>    doesn't have almost no additional complexity when NAN is
>    involved. I believe it qbehaves in the same way
>    and shares a doubious behavior like this.
>
>    =# select '{nan, 1, nan}'::line = '{nan, 2, nan}'::line;
>     ?column?
>    ----------
>     t
>
>    But probably no point in fixing(?) it.

I think we should fix it.

>    The attached file contains line_eq, point_eq_point and
>    circle_same. I expect that line_eq is fast but other two are
>    doubious.

I haven't got an attachment.

>    . . . Mmm.. The function seems broken. I posted the fix for
>    the existing version is posted, and line_perp() in the attched
>    file will work fine.

I am incorporating the fix you have posted to the other thread to this patch.


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrey Borodin
Дата:
Сообщение: Re: New gist vacuum.
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Add more information_schema columns