PostGIS 2.3 release plans

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

PostGIS 2.3 release plans

Regina Obe
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@. 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@.

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@.  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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel
Reply | Threaded
Open this post in threaded view
|

Re: PostGIS 2.3 release plans

Sandro Santilli-4
On Fri, Jul 22, 2016 at 02:11:25AM -0400, Regina Obe wrote:

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

I can help with that, but it's easier if you start the work and
show me some red badge to fight. As said in IRC, you can do
that in a "schema-lock" branch in Gogs, having Winnie and Debbie
build it. Dronnie would be already watching any Gogs branch.

I don't know if it's feasible/easy but it would be nice to have
all those bots badges in the trac ticket, so we can see the status
of the ticket like we'd be seeing the status of a PR.

--strk;
_______________________________________________
postgis-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel
Reply | Threaded
Open this post in threaded view
|

Re: PostGIS 2.3 release plans

Giuseppe Broccolo
In reply to this post by Regina Obe
Hi all,

2016-07-22 8:11 GMT+02:00 Regina Obe <[hidden email]>:

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

About this: I and Julien Rouhaud have already received some comments about our patch
presented in the pull request https://github.com/postgis/postgis/pull/106: we have already
fixed some issues (support for empty entries, make testing "more light") emerged in the
pull request's discussion, and we are waiting for further review of the patch, and ready for
further changes/fixing.

We have also pointed up that travis CI currently runs regression tests on a 9.4 cluster,
so a "successful check" just means that configure steps successfully ignore BRIN code in
pre 9.5 clusters (since BRIN support has been added in 9.5, and our patch correctly manages
the various cases). Anyway, regression tests run successfully for 9.5 and 9.6beta3 clusters.

Regards,
Giuseppe.

--
Giuseppe Broccolo - 2ndQuadrant Italy
PostgreSQL & PostGIS Training, Services and Support
[hidden email] | www.2ndQuadrant.it

_______________________________________________
postgis-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel
Reply | Threaded
Open this post in threaded view
|

Re: PostGIS 2.3 release plans

Daniel Baston
In reply to this post by Regina Obe
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 <[hidden email]> 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

<a href="http://postgis.net/docs/manual-dev/PostGIS_Special_Functions_Index.html#NewF unctions_2_3" rel="noreferrer" target="_blank">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@. 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@.

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@.  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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel


_______________________________________________
postgis-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel
Reply | Threaded
Open this post in threaded view
|

Re: PostGIS 2.3 release plans

Regina Obe
In reply to this post by Giuseppe Broccolo

 

2016-07-22 8:11 GMT+02:00 Regina Obe <[hidden email]>:


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

 

About this: I and Julien Rouhaud have already received some comments about our patch

presented in the pull request https://github.com/postgis/postgis/pull/106: we have already

fixed some issues (support for empty entries, make testing "more light") emerged in the

pull request's discussion, and we are waiting for further review of the patch, and ready for

further changes/fixing.


We have also pointed up that travis CI currently runs regression tests on a 9.4 cluster,

so a "successful check" just means that configure steps successfully ignore BRIN code in
pre 9.5 clusters (since BRIN support has been added in 9.5, and our patch correctly manages

the various cases). Anyway, regression tests run successfully for 9.5 and 9.6beta3 clusters.


Regards,

Giuseppe.

--

 

Giuseppe,

 

I've tested this out and looks generally good.  I'm ready to commit, assuming no one has any issues with that (speak now or forever hold your peace), except for one small little thing which I noted in the pull request.

 

The work as it stands fails our non-extension uninstall test.  To resolve this I'd like to rename the operator families to the same name as the operator classes so it's consistent with the rest of our code base and also so I don't have to muck with our perl uninstall generation script.  As I mentioned, extension installs don't use this script for uninstall (they just use the built-in uninstall plumbing of extension), but our pre-extension test uses this.

 

I've already done this locally, so just a Yes that's okay is all I'm looking for or why you are against that.

 

https://github.com/postgis/postgis/pull/106

 

 

Thanks,

Regina


_______________________________________________
postgis-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel
Reply | Threaded
Open this post in threaded view
|

Re: PostGIS 2.3 release plans

Regina Obe
In reply to this post by Daniel Baston

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:[hidden email]] On Behalf Of Daniel Baston
Sent: Wednesday, July 27, 2016 11:09 AM
To: PostGIS Development Discussion <[hidden email]>
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 <[hidden email]> 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@. 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@.

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@.  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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel

 


_______________________________________________
postgis-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel
Reply | Threaded
Open this post in threaded view
|

Re: PostGIS 2.3 release plans

Greg Troxel

As always, my requeset is to please declare a release candidate, to
publish a release candidate tarball that is exactly what the release
would be (unpacking to the release directory exactly, but it can have
-rc1 in the name - the point is to allow packagers to test the whole
process end to end), and wait at least 2 weeks for people to test,
during which time limit to only documentation changes and minimal bug
fixes for regressions, with no build system cleanup, no new features.
Or if you do make changes that are bigger than minimal doc or regression
fixing, please reset the 2 week timer every time.  Several (at least me)
who package would like to test, but I can't deal with overnight etc. and
instead have to find time.

_______________________________________________
postgis-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel

signature.asc (186 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

trunk passes checks on netbsd-6 amd64

Greg Troxel
In reply to this post by Regina Obe

I did a build of trunk on netbsd-6 amd64 with the following, and after
working around the ticket:3602 build issue, got a a successful make
check (including the new json-c stuff, which had failed before I added
that to configure).

PostgreSQL 9.3.13 on x86_64--netbsd, compiled by gcc (NetBSD nb2 20110806) 4.5.3, 64-bit
Postgis 2.3.0dev - r15025 - 2016-07-30 16:19:19
scripts 2.3.0dev r15025
GEOS: 3.5.0-CAPI-1.9.0 r4084
PROJ: Rel. 4.9.2, 08 September 2015

_______________________________________________
postgis-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel

signature.asc (186 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: trunk passes checks on netbsd-6 amd64

Regina Obe
Greg,

I fixed this issue (well never had it), but based on your suggestions.  Can you try it next when you get the chance.  Also backported to 2.2 branch for when we release 2.2.3.

Please give it a try when you have the chance to confirm it fixes your issue and doesn't introduce new ones.  The tiger one also included a fix for a separate ticket (that tiger_data would not be dumpted out by pg_dump since pg_dump won't dump out schemas owned by an extension).

Thanks for testing,
Regina

-----Original Message-----
From: postgis-devel [mailto:[hidden email]] On Behalf Of Greg Troxel
Sent: Saturday, July 30, 2016 12:27 PM
To: [hidden email]
Subject: [postgis-devel] trunk passes checks on netbsd-6 amd64


I did a build of trunk on netbsd-6 amd64 with the following, and after working around the ticket:3602 build issue, got a a successful make check (including the new json-c stuff, which had failed before I added that to configure).

PostgreSQL 9.3.13 on x86_64--netbsd, compiled by gcc (NetBSD nb2 20110806) 4.5.3, 64-bit Postgis 2.3.0dev - r15025 - 2016-07-30 16:19:19 scripts 2.3.0dev r15025
GEOS: 3.5.0-CAPI-1.9.0 r4084
PROJ: Rel. 4.9.2, 08 September 2015

_______________________________________________
postgis-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel
Reply | Threaded
Open this post in threaded view
|

Re: PostGIS 2.3 release plans

Giuseppe Broccolo
In reply to this post by Regina Obe
Hi Regina,

2016-07-29 20:29 GMT+02:00 Regina Obe <[hidden email]>:


Giuseppe,

 

I've tested this out and looks generally good.  I'm ready to commit, assuming no one has any issues with that (speak now or forever hold your peace), except for one small little thing which I noted in the pull request.

 

The work as it stands fails our non-extension uninstall test.  To resolve this I'd like to rename the operator families to the same name as the operator classes so it's consistent with the rest of our code base and also so I don't have to muck with our perl uninstall generation script.  As I mentioned, extension installs don't use this script for uninstall (they just use the built-in uninstall plumbing of extension), but our pre-extension test uses this.

 

I've already done this locally, so just a Yes that's okay is all I'm looking for or why you are against that.

 

https://github.com/postgis/postgis/pull/106


There is no problem in renaming the OpFamily. Sorry, I've understood that you already proceeded with this. So yes, please rename it (is the problem present just for the geography OpFamily?).

Regards,
Giuseppe.

--
Giuseppe Broccolo - 2ndQuadrant Italy
PostgreSQL & PostGIS Training, Services and Support
[hidden email] | www.2ndQuadrant.it

_______________________________________________
postgis-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel
Reply | Threaded
Open this post in threaded view
|

Re: PostGIS 2.3 release plans

Regina Obe

Probably is same for all.  It was just geography that got hit first.  But I found all of them and renamed.

 

I'll go ahead and commit now.

 

Thanks for confirming,

Regina

 

From: postgis-devel [mailto:[hidden email]] On Behalf Of Giuseppe Broccolo
Sent: Saturday, July 30, 2016 5:22 PM
To: PostGIS Development Discussion <[hidden email]>
Subject: Re: [postgis-devel] PostGIS 2.3 release plans

 

Hi Regina,

 

2016-07-29 20:29 GMT+02:00 Regina Obe <[hidden email]>:

 

Giuseppe,

 

I've tested this out and looks generally good.  I'm ready to commit, assuming no one has any issues with that (speak now or forever hold your peace), except for one small little thing which I noted in the pull request.

 

The work as it stands fails our non-extension uninstall test.  To resolve this I'd like to rename the operator families to the same name as the operator classes so it's consistent with the rest of our code base and also so I don't have to muck with our perl uninstall generation script.  As I mentioned, extension installs don't use this script for uninstall (they just use the built-in uninstall plumbing of extension), but our pre-extension test uses this.

 

I've already done this locally, so just a Yes that's okay is all I'm looking for or why you are against that.

 

https://github.com/postgis/postgis/pull/106

 

There is no problem in renaming the OpFamily. Sorry, I've understood that you already proceeded with this. So yes, please rename it (is the problem present just for the geography OpFamily?).

 

Regards,

Giuseppe.

--

Giuseppe Broccolo - 2ndQuadrant Italy
PostgreSQL & PostGIS Training, Services and Support
[hidden email] | www.2ndQuadrant.it


_______________________________________________
postgis-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel