Horton
Menu

Re: point_ops for GiST

Emre Hasegeli <emre@hasegeli.com>

View thread
From: Emre Hasegeli <emre@hasegeli.com>
To: Alexander Korotkov <a.korotkov@postgrespro.ru>
Cc: Stefan Keller <sfkeller@gmail.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>, Teodor Sigaev <teodor@sigaev.ru>, Pgsql Hackers <pgsql-hackers@postgresql.org>
Date: 2015-10-12T10:32:59Z
Lists: pgsql-hackers 
>> 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?
>
>
> Note, that PostGIS is a different project which is maintained by separate
> team. PostGIS have its own priorities, development plan etc.
> PostgreSQL have to be self-consistent. In particular, it should have
> reference implementation of operator classes which extensions can use as the
> pattern. This is why it's important to maintain built-in geometric types.
>
> In short: once we implement it for built-in geometric types, you can ask
> PostGIS team to do the same for their geometry/geography.

The problem is that geometric types don't even serve well to this
purpose in their current state.  We have to make the operators
consistent to better demonstrate index support of cross type
operators.

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix gist_box_same and gist_point_consistent to handle fuzziness correctly.

  2. Add point_ops opclass for GiST.