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

[Paul Ramsey]

> 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