Re: point_ops for GiST - Mailing list pgsql-hackers

From Emre Hasegeli
Subject Re: point_ops for GiST
Date
Msg-id CAE2gYzxBsuu4334dSUmpSyLYCLGAk9xbic3powmnyrnbFf5JaQ@mail.gmail.com
Whole thread Raw
In response to Re: point_ops for GiST  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: point_ops for GiST  (Stefan Keller <sfkeller@gmail.com>)
List pgsql-hackers
> Emre Hasegeli just pointed out to me that this patch introduced
> box_contain_pt() and in doing so used straight C comparison (<= etc)
> instead of FPlt() and friends.  I would think that that's a bug and
> needs to be changed -- but certainly not backpatched, because gist
> indexes would/might become corrupt.

The problem with this is BRIN inclusion opclass uses some operators to
implement others.  It was using box @> point operator to implement
point ~= point operator by indexing points in boxes.  The former
doesn't use the macros, but later does.  The opclass could return
wrong result when the point right near the index boundaries.

Currently, there are not BRIN opclasses for geometric types except box
because of this reason.  I would like to work on supporting them for
the next release.  I think the best way is to change the operators
which are not using the macros to be consistent with the others.  Here
is the list:

* polygon << polygon
* polygon &< polygon
* polygon &> polygon
* polygon >> polygon
* polygon <<| polygon
* polygon &<| polygon
* polygon |&> polygon
* polygon |>> polygon
* box @> point
* point <@ box
* lseg <@ box
* circle @> point
* point <@ circle

I can send a patch, if it is acceptable.



pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: Why does replication need the old history file?
Next
From: Peter Geoghegan
Date:
Subject: Re: 9.5 release notes