Re: point_ops for GiST

From: Emre Hasegeli <emre(at)hasegeli(dot)com>
To: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>
Cc: Stefan Keller <sfkeller(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: point_ops for GiST
Date: 2015-10-12 10:32:59
Message-ID: CAE2gYzz=u1hfYoCa4fx3B53QTy87c=e7kYEwqLf_pyLuzh9zNA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2015-10-12 11:16:25 Re: Postgres service stops when I kill client backend on Windows
Previous Message Magnus Hagander 2015-10-12 10:26:15 Re: Postgres service stops when I kill client backend on Windows