[postgis-devel] PSC Vote: Change PostGIS library name to drop the minor

Wed Sep 6 10:40:27 PDT 2017

Komzpa,

I think PostGIS and pgRouting are probably the biggest extensions you'll find so our features change a lot more than other PostgreSQL versions.

4 reasons I can think of and they aren't very strong reasons.

1)      We may want to rename C functions in PostGIS 3.0 which underly SQL functions.  In that case pg_upgrade would fail, though regular

ALTER EXTENSION .. UPDATE  would still work.

So that's not a killer reason not to.  The only other reason not to would be we may want to change the on-disk storage of PostGIS as we did going from 1.5  to 2.0  which would make it not possible to do an upgrade without 

Dump / restore

Then again pg_upgrade would probably just fail so again not a huge reason not to do that.

2)      Third reason which is really why I mentioned it makes more sense for pgRouting to do it than us since they are in major flux breaking backward compatibility in non-trival ways. 

WE are as far as 2 series are pretty stable, worst we do is deprecate a function no one should be using anyway.

In 3  we might completely break backward compatibility in a super serious way.  I mean go really crazy like change how you call ST_Union or something to require you pass in your geometry as a jsonb.  In that case, your old code may not work with new PostGIS and in that case, you might really really want to run PostGIS 2  and PostGIS 3 in the same cluster but different databases just to contrast and compare how you need to change stuff.

Even then you'd probably be better off running in a different cluster anyway.

So that leaves us with the 3rd reason

3)      When developing PostGIS I do like the convenience of being able to run two different versions of PostGIS in the same PostgrSQL instance mainly for regression.  

That convenience I'd like to keep (as I mentioned with a ./configure –use-minor-version switch), but I think it's a convenience for me that causes a lot more pain for others. A convenience I'm willing to give up if requires.

The convenience is even more useful  with pgRouting because in pgRouting in general there are no types bound to your data.  That means it's pretty trivial to upgrade / downgrade in pgRouting

With 

CREATE EXTENSION pgRouting VERSION "2.5.0";

DROP EXTENSION pgRouting;

CREATE EXTENSION pgRouting VERSION "2.4.1";

And do regression tests with the same exact data.

This nice feature of pgRouting we can't have because all our data is tied to PostGIS, so a DROP EXTENSION of postgis can not be done without losing your data.

From: postgis-devel [mailto:postgis-devel-bounces at lists.osgeo.org] On Behalf Of Darafei "Kom?pa" Praliaskouski
Sent: Wednesday, September 06, 2017 1:05 PM
To: PostGIS Development Discussion <postgis-devel at lists.osgeo.org>
Subject: Re: [postgis-devel] PSC Vote: Change PostGIS library name to drop the minor

I've looked at my /usr/lib/postgresql/10/lib/ directory and it seems postgis and pgrouting are the only libraries that attempt to have version in their name.

Any reason not to call the library postgis.so, not even postgis-2.so, and keep symbols from as far as current supported upgrade path allows?

ср, 6 сент. 2017 г. в 19:00, Regina Obe <lr at pcorp.us <mailto:lr at pcorp.us> >:

I want to itemize my key points

1) If we did not try to support PostgreSQL versions that couldn't fully support the key features of a PostGIS version, we wouldn't have such a mess with half-broken pg_upgrade installs.
That means we should never have supported anything lower than 2.2 in PostgreSQL 9.5 and not supported anything lower than 9.5 in 2.3 (the parallel stuff since we didn't do much with marking aggs as parallel safe in 9.5 ), it was okay to support 9.5 in 2.3.  2.4 should really not be supporting anything other than 9.6 and 10. I know it sound draconian but I really think it's the best for the majority of people.

If we feel really badly about supporting older versions then we've got to put a lot more work into it to prevent half-broken installs.

2) If we just called our library  postgis-2 instead of postgis-2.5 or whatever, then

All users will be coming from a lower postgis -- e.g. postgis-2.4.0 or postgis-2.3  etc.
We can provide a clean path for folks coming from lower versions because ALTER EXTENSION can recognize something needs to be done
For pg_upgrade  we can creating a symlink from older versions to postgis-2 and putting in all our dirty cleanup laundry in postgis-2.5 scripts to correct our past sins.

3) Moving forward don't try to let old versions pass just because they can't support a key feature of our new version.
Don't try to support newer versions of PostgreSQL with old code.  It makes us look like liars when people read the "Aha you can do this now literature" and they can't.

If our postgis library file was just called postgis-2   then we are free to do drop PostgreSQL versions as we see fit andnot impact anyone's upgrade path or screw up their install in a hard to fix way.

Thanks,
Regina

-----Original Message-----
From: Regina Obe [mailto:lr at pcorp.us <mailto:lr at pcorp.us> ]
Sent: Wednesday, September 06, 2017 11:34 AM
To: 'PostGIS Development Discussion' <postgis-devel at lists.osgeo.org <mailto:postgis-devel at lists.osgeo.org> >
Subject: RE: [postgis-devel] PSC Vote: Change PostGIS library name to drop the minor

>> It would also solve the issue we have that PostgreSQL 9.4 2.4 upgrading to PostgreSQL 9.6 2.4 is missing all the good stuff like true KNN and some parallel safe stuff we put in.

> No, this is untrue. The KNN and parallel stuff requires *scripts* rebuild and reload, so has nothign to do with the library/module.

> --strk;

I beg to differ again.

If a user has PostgreSQL 9.4 2.4 installed and they migrate to PostgreSQL 9.6 2.4

When they go to do

ALTER EXTENSION postgis UPDATE;

Nothing would happen.  It would say they are already current.  Even your favorite old-fashioned we have in place will not catch that.

However if they were coming from say

PostgreSQL 9.4 2.1  before we introduced all this KNN stuff and Parallel stuff that 9.4 can't use anyway -- but we let it pass (oh you can't support that lets not give you that).

ALTER EXTENSION postgis UPDATE;

Would run the bits we said you need to run to move from 2.1 to 2.4  which would be adding in the KNN logic, dropping and recreating aggs that need to be.

Sure you can argue we can add that in the future, but there is no way when we call a script 2.4.0 that ALTER EXTENSION postgis UPDATE would try to do anything.

Sure we could add another function and instruct users.

Oh and if ALTER EXTENSION postgis UPDATE says you need to do nothing, don't believe it.

Run

SELECT postgis_full_version();

Make sense of our gobbly gook

If you see a message that something to the effect yaddda yadda yadda, then run this

.sql script  which will update the function to update your code.

And then you are good.

How much freaking stuff do you expect people to do.
People are already struggling to type the words:

ALTER EXTENSION postgis UPDATE;

It's hard for both us and them.  Us to try to account for all the different versions of PostgreSQL you could have upgraded from and hard for them to make sense of what you are asking them to do.

You know how freaking hard it is to explain to users in training.  Oh that KNN stuff we talked about that is new in PostGIS 2.2., well forget about it if you are running PostgreSQL 9.4 or lower.

And if you hmm upgraded in the past some time using pg_ugrade, you don't get it either.  You need to fuck with your install or do a pg_dump / pg_restore.

Thanks,
Regina

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

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