Re: [HACKERS] compress method for spgist - 2
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] compress method for spgist - 2 |
Дата | |
Msg-id | 9463.1505952885@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] compress method for spgist - 2 (Alexander Korotkov <aekorotkov@gmail.com>) |
Ответы |
Re: [HACKERS] compress method for spgist - 2
|
Список | pgsql-hackers |
Alexander Korotkov <aekorotkov@gmail.com> writes: > On Thu, Sep 21, 2017 at 2:06 AM, Darafei "Komяpa" Praliaskouski < > me@komzpa.net> wrote: >> What is rationale behind this circle? > I would prefer to rather forbid any geometries with infs and nans. > However, then upgrade process will suffer. User with such geometries would > get errors during dump/restore, pg_upgraded instances would still contain > invalid values... Yeah, that ship has sailed unfortunately. >> It seems to me that any circle with radius of any Infinity should become a >> [-Infinity .. Infinity, -Infinity .. Infinity] box.Then you won't have >> NaNs, and index structure shouldn't be broken. > We probably should produce [-Infinity .. Infinity, -Infinity .. Infinity] > box for any geometry containing inf or nan. Hm, we can do better in at least some cases, eg for a box ((0,1),(1,inf)) there's no reason to give up our knowledge of finite bounds for the other three boundaries. But certainly for a NaN circle radius what you suggest seems the most sensible thing to do. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
В списке pgsql-hackers по дате отправления: