Re: [HACKERS] Floating point comparison inconsistencies of thegeometric types

Поиск
Список
Период
Сортировка
От Emre Hasegeli
Тема Re: [HACKERS] Floating point comparison inconsistencies of thegeometric types
Дата
Msg-id CAE2gYzzwx0Eh0LA4M=HkquxA4FqinXWpB7vMaumzYmKqkF24PQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Floating point comparison inconsistencies of thegeometric types  (Robert Haas <robertmhaas@gmail.com>)
Ответы [HACKERS] Re: Floating point comparison inconsistencies of the geometrictypes  (David Steele <david@pgmasters.net>)
Список pgsql-hackers
> Got it, but if other people don't agree then this is going nowhere.

Yes.  As I wrote, I don't particularly care about functions like "is
point on line".  I can prepare a patch to fix as many problems as
possible around those operators by preserving the current epsilon.

I though we were arguing about *all* operators.  Having containment
and placement operators consistent with each other, is the primary
thing I am trying to fix.  Is removing epsilon from them is
acceptable?

We can also stay away from changing operators like "~=" to minimise
compatibility break, if we keep the epsilon on some places.  We can
instead document this operator as "close enough", and introduce
another symbol for really "the same" operator.

That said, there are some places where it is hard to decide to apply
the epsilon or not.  For example, we can keep the epsilon to check for
two lines being parallel, but then should we return the intersection
point, or not?  Those issues may become more clear when I start
working on it, if preserving epsilon for those operators is the way to
go forward.



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

Предыдущее
От: Erik Rijkers
Дата:
Сообщение: Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands:\quit_if, \quit_unless)
Следующее
От: Emre Hasegeli
Дата:
Сообщение: Re: [HACKERS] [PATCH]: fix bug in SP-GiST box_ops