[postgis-devel] PostGIS 2.3 release plans

Fri Jul 29 11:33:51 PDT 2016

Just for closure, I already mentioned this to Dan on github ticket.  

This is going to be pushed to PostGIS 2.4 since I think it unlikely we'll have GEOS 3.6 out before 2.3 release (unless strk has other opinions) also not much time for Dan to work out the issues aside from that.

Right now only things we have dependent on GEOS 3.6 besides this is the ST_MinimumClearance and ST_MinimumClearanceLine which as I recall can be used to replace much of our existing ST_MinimumBoundingCircle thus fixing some of issues people have complained about and probably improving speed as well.

Thanks,

Regina

From: postgis-devel [mailto:postgis-devel-bounces at lists.osgeo.org] On Behalf Of Daniel Baston
Sent: Wednesday, July 27, 2016 11:09 AM
To: PostGIS Development Discussion <postgis-devel at lists.osgeo.org>
Subject: Re: [postgis-devel] PostGIS 2.3 release plans

Hi Regina,

I'm not able to work on the precision model support at the moment.  I'd be fine with pushing this off a release.  That said, the precision model work stalled when I came across some warts in the exposure of precision models in the GEOS C API.  I'm assuming GEOS 3.6 would be released around the same time as PostGIS 2.3, so if we are going to make changes to the GEOS CAPI we'd need to do them before PostGIS 2.3, right?  (See https://lists.osgeo.org/pipermail/postgis-devel/2016-March/025714.html)

There are also some simple easy window functions that I think would be nice to add in 2.3 (Average Distance, Sum Distance, etc), but again, I'm not able to work on them right now.

Thanks,

Dan

On Fri, Jul 22, 2016 at 2:11 AM, Regina Obe <lr at pcorp.us <mailto:lr at pcorp.us> > wrote:

I think it's time we start putting a stake in the ground for PostGIS 2.3.

I would like us to release in mid September, primarily so we don't have to
support PostgreSQL 9.6 on PostGIS 2.2.  I'm hoping PostgreSQL 9.6 slated
release of September will be a little late as usual to buy us more time
which I think there is a good chance of given they are at beta2 (and still
have at least one rc to go).

I would also like to call feature freeze by early to mid August.  That said,
this is what I know we have in works or completed - much self-centered
around me cause I know more about what I have to do than what others have to
do.

1) Several functions already in place - our very first set of window
functions which I'm pretty excited about and other nice functions like
ST_Voronoi, ST_GeneratePoints
Plus some performance enhancements

http://postgis.net/docs/manual-dev/PostGIS_Special_Functions_Index.html#NewF <http://postgis.net/docs/manual-dev/PostGIS_Special_Functions_Index.html#NewFunctions_2_3> 
unctions_2_3

(so nothing to do here except more testing. Some I've already stress tested
a bit).

2) More testing on parallelism with PostgreSQL 9.6 (beta2 has a bunch of
fixes for parallel support I need to test). Marking costs on more functions.
Paul Ramsey already marked off PostGIS geometry/geography functions and Paul
Norman provided costs.
I marked off raster ones that I think are parallel safe.  I still need to
stress test and compare with old behavior on real work-loads and make sure
no crashing and burning and come up with costs for raster functions.

-- Things not yet committed but on the horizon slated for PostGIS 2.3 at
this point ( 8 pull requests - https://github.com/postgis/postgis/pulls )
3) Making PostGIS non-relocatable and schema qualifying function calls.
This I may need help with: As I stated in PostGIS 2.3, we need to schema
qualify our function calls primarily because setting search_path on
functions breaks inlining behavior needed for functions that utlize spatial
indexes and without schema qualification all sorts of things fall apart like

materialized views, backup / restore , logical decoding replication etc.
A good chunk of this was patched with optional helper script released in
PostGIS 2.2.2 to set function search_path (but functions that rely on
indexes could not be patched)

My proposal is outlined here:

https://trac.osgeo.org/postgis/ticket/3496

I could do it all myself if all we had to worry about was building for
extensions. To support the old-fashioned way, I may need some help.

The part I need help with is revising our perl scripts, to take in an extra
argument (whether to replace @extschema at . with the default schema specified
during configure (if any) or take it out if non-specified.

So I would change all the functions that call other functions to use
@extschema at .

For extension include, this will be unchanged, since extension plumbing
handles replace for that already.  For non-extension installs, this would
either be

replace @extschema at .  with nothing, or replaced with what a user passes in
for PostGIS install location during configure.

So our perl scripts need to take an additional parameter to denote if they
should strip out that, replace it, or do nothing with it.  I guess this can
be done after the script pass by adding another
Step in our generation.

The extension install can no longer use what was already built for the
old-fashioned install since it would have the @extchema@ stripped or
hard-coded with some schema and extension script will need this untouched.

4) Tiger 2016 upgrade for postgis_tiger_geocoder - I expect new Tiger data
will be out in August and plan to patch the load scripts to support.

5) BRIN support -- I think some cleanup is still left with that patch being
worked on, but looks pretty close for commit. -
https://github.com/postgis/postgis/pull/106  So I would consider it a done
deal except, it's not in our code base yet.  I want this in before
mid-August so we can start stress testing it.

6) Precision Model support - Dan how much more do you have left before you
can commit? https://github.com/postgis/postgis/pull/100 (or do we need to
push to PostGIS 2.4?)
7) ST_Angle function - https://github.com/postgis/postgis/pull/97
8) Validity Flag - https://github.com/postgis/postgis/pull/99
9) ST_AsText -- adding optional precision argument --
https://github.com/postgis/postgis/pull/94
10) ST_AsGeoBuf -- https://github.com/postgis/postgis/pull/108  (still seems
a bit to go so may not make an August cut without some loving)

Feel free to add anything I missed and if I forgot your favorite patch, I'm
sorry in advance.

Thanks,
Regina

_______________________________________________
postgis-devel mailing list
postgis-devel at lists.osgeo.org <mailto:postgis-devel at lists.osgeo.org> 
http://lists.osgeo.org/mailman/listinfo/postgis-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20160729/0f189815/attachment.html>