Hi Emre
Pls. don't misunderstand my questions: They are directed to get an
even more useful spatial data handling of PostgreSQL. I'm working with
PostGIS since years and are interested in any work regarding spatial
types...
Can anyone report use cases or applications of these built-in geometric types?
Would'nt it be even more useful to concentrate to PostGIS
geometry/geography types and extend BRIN to these types?
:Stefan
2015-06-13 23:04 GMT+02:00 Emre Hasegeli <emre@hasegeli.com>:
>> 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.
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
