[OSGeo-Discuss] PostGIS 3.0.0alpha1 released

[Regina Obe]

The PostGIS development team is pleased to release PostGIS 3.0.0alpha1.

This release works with PostgreSQL 9.5-12beta1  and GEOS >= 3.6

Best served with PostgreSQL 12beta1.

Details at: https://postgis.net/2019/05/26/postgis-3.0.0alpha1/

 

 

Source: https://download.osgeo.org/postgis/source/postgis-3.0.0alpha1.tar.gz

Docs PDF: https://download.osgeo.org/postgis/docs/postgis-3.0.0alpha1.pdf

Docs HTML:
https://download.osgeo.org/postgis/docs/doc-html-3.0.0alpha1.tar.gz

NEWS: https://git.osgeo.org/gitea/postgis/postgis/raw/tag/3.0.0alpha1/NEWS

 

Aside from the added functions and enhancements detailed in the news

The major changes that make PostGIS 3.0 different from prior versions

 

1)      The raster support has been broken out into its own extension so
from PostGIS 3 and moving forward to get raster support you need to install
the raster extension as follows:

 

CREATE EXTENSION postgis;

CREATE EXTENSION postgis_raster;

 

This was to satisfy non-raster users wanting fewer functions in their
postgis install and also to allow those folks 

who can't build with GDAL support to still be able to use PostgreSQL
extension plumbing for installing postgis

 

 

2)      The Lib minor has been removed by default from the lib file.

This was done to ease future pg_upgrade.

So from now  for each PostGIS 3 minor that follows

e.g. 3.1, 3.2 etc

 

the lib files will remain the same with extension -3 instead of -3.1, -3.2
and so forth.

Any removals of functions we do from now on will be stubbed with an error so
that pg_upgrade can be  done smoothly from prior PostgreSQL installs.

 

 

3)      This one is specifically designed for PostgreSQL 12 - PostgreSQL 12
is the first version to no longer rely on SQL inlining.

For more than 10 years - PostGIS has been relying on what is called - SQL
inlining - which allows us to define the function  ST_Intersects and many
others as a combination of  && and _ST_Intersects  because && was the only
piece that could use the index and the planner would peak into the function
and break them apart into separate steps.

 

This has prevented us from properly costing our functions because if they
are costed right, then inlining  breaks and the index never kicks in.

It also would just for whatever reason on occasion when the planner decided
not to inline the function, result in very slow queries.

People have complained on the list on occasion of cases where the index did
not kick in as a result.

 

PostgreSQL 12 introduced support functions in operator definition that
PostGIS 3 uses for ST_Intersects and family so that the function can
natively use the index without any inlining tricks.  This means we can now
start properly costing things and also result in better plans since the
planner won't accidentally not use an index because it decided not to
inline.

 

4)      For those running Proj6+ PostGIS 3.0 is first version to leverage
Proj6 features - refer to -
http://blog.cleverelephant.ca/2019/02/proj4-postgis.html

5)      postgis.backend GUC has been removed.  The main reason for its
existence was to allow same named SFCGAL functions to take over the
behavior.

The 3D functions in postgis like ST_3DIntersects that couldn't support TINS
or solid 3D geometries have been augmented to support these so no longer
need SFCGAL to achieve the same functionality and same named functions were
from from postgis_sfcgal extension.

 

 

Please test in particular the above features (more itemized in the NEWs) and
report back if anything does not behave as you would expect.

 

Happy spatial querying,

PostGIS Development Team

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/discuss/attachments/20190526/1956a8bf/attachment.html>