Re: point_ops for GiST
Stefan Keller <sfkeller@gmail.com>
From: Stefan Keller <sfkeller@gmail.com>
To: Pgsql Hackers <pgsql-hackers@postgresql.org>
Cc: Emre Hasegeli <emre@hasegeli.com>,
Alexander Korotkov <a.korotkov@postgrespro.ru>,
Alvaro Herrera <alvherre@2ndquadrant.com>,
Robert Haas <robertmhaas@gmail.com>,
Teodor Sigaev <teodor@sigaev.ru>
Date: 2015-10-12T20:28:39Z
Lists: pgsql-hackers
Hi Alexander Thanks for your succinct reply. Actually I considered contributing myself for the first time to PostgreSQL and/or PostGIS. So, concluding from your explanations there's no big use case behind build-in geometric types except serving as reference implementation? I'm still torn over this splitting resources to implement types like geometry twice. :Stefan 2015-10-12 11:24 GMT+02:00 Alexander Korotkov <a.korotkov@postgrespro.ru>: > Hi, Stefan! > > On Sun, Oct 11, 2015 at 10:00 PM, Stefan Keller <sfkeller@gmail.com> wrote: >> >> 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. > > ------ > Alexander Korotkov > Postgres Professional: http://www.postgrespro.com > The Russian Postgres Company >
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix gist_box_same and gist_point_consistent to handle fuzziness correctly.
- 3c29b196b0ce 9.3.0 cited
-
Add point_ops opclass for GiST.
- 4cbe47393877 9.0.0 cited