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
_______________________________________________ Discuss mailing list Discuss@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/discuss
