== Purpose

This page is not a list of things that **will happen** it is a place to gather disruptive changes that might make sense for a PostGIS 3 release.

== Ideas

* Break out a `postgis_raster` extension with a `postgis` dependency, so raster support becomes optional (experimental implementation: https://git.osgeo.org/gitea/postgis/postgis/pulls/20).
* Require installation in a 'postgis' schema, always and for ever
* Get rid of the Minor version in the lib file or at least make it not the default compile option, so pg_upgrade is easier for users
* Yet another serialization, this time changing to use `external` storage type, and adding our own compression scheme for coordinates.
  * An uncompressed header, so header info can always be efficiently "sliced" and read, even for very large objects
  * A hash key for use in fast and small equality comparisons (for use in cached comparison code)
  * A compression format optimized for doubles
  * Other compression formats with other tradeoffs (?) like TWKB for higher ratio with precision loss
  * Implies indirection in coordinate access again: smaller, more efficient must be balanced against direct access to coordinates
* Move up to "modern" C and use whatever cool features we like from that
* Modern GEOS version requirement?
  * Some major GEOS surgery to allow memory management by palloc?
  * Some major GEOS surgery to build coordinateSequence directly on top of PostGIS pointlists?

* Have some strategy for storing and tracking coordinate precision
* Make "PostGIS" source tree an even thin(ner?) wrapper that exposes other code to Postgres. Leave almost no processing logic here.
* Consider using C++ for some of what is currently in the "lwgeom" source tree
* Use GEOS C++ API to avoid verbose, complex code from dealing w/CAPI
* Build adapters to LWGEOM to boost::geometry and CGAL types so we can use those libraries directly