Re: compress method for spgist - 2
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: Darafei Komяpa Praliaskouski <me@komzpa.net>, Nikita Glukhov <n.gluhov@postgrespro.ru>, pgsql-hackers <pgsql-hackers@postgresql.org>, Heikki Linnakangas <hlinnaka@iki.fi>, Fedor Sigaev <teodor@sigaev.ru>
Date: 2017-09-21T00:14:45Z
Lists: 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
Commits
-
Doc: remove duplicate poly_ops row from SP-GiST opclass table.
- d3b851e9a3c9 11.0 landed
-
Add polygon opclass for SP-GiST
- ff963b393ca9 11.0 landed