[postgis-devel] PostGIS 2.3 release plans

Wed Jul 27 08:08:36 PDT 2016

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> 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
> 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
> http://lists.osgeo.org/mailman/listinfo/postgis-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20160727/97fd2adb/attachment.html>