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

[Regina Obe]

Paul,

> in some respects this is also a  magic  upgrade since if you forget the finally step your system will still probably work since 99.9% of the old functions will still bind to the new postgis.so.
Yap much better than we have now with people running 2.2so thinking they are running 2.3.so or some packager removing the old .so thinking you are done with it and breaking your database.


>  It seems like a  least worst  option given the current state of affairs, though I d rather do it for 3.x than a 2.x. YMMV kind of a thing.

What do you think would be special about 3.0 that you want to wait till then and would even want to call it 3.0?

I'd much rather do this in 2 because if done in 2.5, we can conceivably provide an easy migration path for users
Running 2.2 - 2.4 simply by having our install auto-create a symlink to versions like PostgreSQL 10 and PostgreSQL 11 where we won't be providing a PostGIS 2.3.

If you call it 3 - we are going to be dropping a lot of PostgreSQL versions by then I imagine.  Everyone will have to do a dump /reload or have 2 and 3 installed.
Which means they'd have to do lots of hops if they are coming from say 9.4.

What kind of wonderfulness can we promise in a 3 version to warrant such a great  burden.

I'd like a nice big horse with a bow on top. :)


Thanks,
Regina



 

-----Original Message-----
From: Paul Ramsey [mailto:pramsey at cleverelephant.ca] 
Sent: Tuesday, September 05, 2017 3:54 PM
To: PostGIS Development Discussion <postgis-devel at lists.osgeo.org>
Cc: Regina Obe <lr at pcorp.us>; Devrim Gündüz <devrim at gunduz.org>
Subject: Re: [postgis-devel] PSC Vote: Change PostGIS library name to drop the minor


> On Sep 5, 2017, at 10:58 AM, Mark Cave-Ayland <mark.cave-ayland at ilande.co.uk> wrote:
> 
> On 04/09/17 23:08, Regina Obe wrote:
> 
>> Creating a symlink from postgis-2.4  (compiled for PostgreSQL 10)  
>> and calling the link postgis-2.3 is a lot less evil I think.
>> 
>> In fact your PostGIS will still work after upgrade even if you don't 
>> rush to do
>> 
>> ALTER EXTENSION postgis UPDATE;
>> 
>> Because we did not remove any functions exposed via the SQL scripts.  We only added functions.
>> 
>> You can even do this for postgis-2.2 and you'll be fine.
>> 
>> But as Darafei pointed out in the last comment
>> 
>> 
>> https://gist.github.com/Komzpa/994d5aaf340067ccec0e
>> 
>> Many people just don't get that.  It's a hard thing for people to fathom.
>> 
>> That you can take   postigs-2.4 compiled for PostgreSQL 10 and call it postgis-2.3 PostgreSQL 10 and it will work.
>> 
>> BUT
>> 
>> postgis-2.3 compiled for PostgreSQL 9.6  CAN NOT BE USED by something 
>> looking for PostgreSQL 10 postgis-2.3 (though they both have 2.3 they are incompatible).
>> 
>> Thus my need to just ditch the minor to make every one's life easier.
> 
> Sure, I understand this. But reiterating my point from a previous 
> email, pg_upgrade exists to update any on-disk binary changes and 
> internal APIs. The assumption is that all other external libraries 
> will remain the same, however I'm uncertain exactly what "the same" 
> means in PostgreSQL terms.
> 
> For example if PostgreSQL 10 makes a binary change to the Datum struct 
> or the AnalyzeStats struct compared to 9.6 then there is nothing we 
> can do about this without a recompile, and I can't see how dropping 
> the minor version would help here. So from what you are saying above, 
> does that mean such a breaking change has taken place between 9.6 and 10?

There s a core assumption that the versions of postgis and pgsql folks would be using would be kept functionally in sync through the mechanism of packaging: if you re upgrading from 

postgresql-9.5
postgresql-9.5-postgis-2.3

to 

postgresql-9.6
postgresql-9.6-postgis-2.4

then you can do a process of 

- install new packages (now your install it dead until you)
- pg_upgrade
- start up your new instance
- finally ALTER EXTENSION postgis UPDATE  

in some respects this is also a  magic  upgrade since if you forget the finally step your system will still probably work since 99.9% of the old functions will still bind to the new postgis.so.

It seems like a  least worst  option given the current state of affairs, though I d rather do it for 3.x than a 2.x. YMMV kind of a thing.

It would be nice if the pgsql extension mechanism had a hook where it could ask the extension what it thinks its version is, so that pgsql itself could raise the issue  hey, your extension thinks it s version 3.0, but your library is version 3.1, want to fix that? .  

Because the final black box at the end of all this stuff is the fact that the  ALTER EXTENSION UPDATE  step seems like extra voodoo: "why do I have to do this, I already installed the update via yum/apt-get, right?"

ATB,
P


> 
> 
> ATB,
> 
> Mark.
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel