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

Tue Sep 5 13:21:39 PDT 2017

I should add to this as strk and I both realized.  We are screwing users when they move say from PostGIS 2.2 9.4 to PostGIS 2.2 9.5

And that is currently not recoverable.  Something we really need to fix.  

That's why we have on occasion like this poor fellow running PostGIS 2.2 with PostgreSQL 9.5 thinking he'd get the benefits of KNN and to his disappoint he did not.

That’s the other reason I'd like to stop supporting versions of PostgreSQL that can't take full feature of a PostGIS version.  It's so easy to mess them up.

https://lists.osgeo.org/pipermail/postgis-users/2017-August/042287.html

I'd just assume minimize it by making it much easier for people to upgrade PostGIS and PostgreSQL at the same time.

It would be much easier if we didn't try to support PostgreSQL versions that can't fully take advantage of a feature than upgrading to a newer PostgreSQL would go so much more smoothly

Assuming we didn't continually change our lib name.

From: postgis-devel [mailto:postgis-devel-bounces at lists.osgeo.org] On Behalf Of Paul Ramsey
Sent: Tuesday, September 05, 2017 4:02 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

On Sep 5, 2017, at 12:59 PM, Darafei Komяpa Praliaskouski <me at komzpa.net <mailto:me at komzpa.net> > wrote:

Can PostGIS detect version mismatch (the NEED UPGRADE in full_version) and either perform a self-upgrade on first launch, or fail early with version mismatch message if it, say, doesn't have permissions?

Yes, it can figure out it has a mismatch (the so-called “script versions” checks you can see do that) but it does lack the power to do a self-upgrade in general. That requires a super-user.

P

вт, 5 сент. 2017 г. в 22:53, Paul Ramsey <pramsey at cleverelephant.ca <mailto:pramsey at cleverelephant.ca> >:

> On Sep 5, 2017, at 10:58 AM, Mark Cave-Ayland <mark.cave-ayland at ilande.co.uk <mailto: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 <mailto:postgis-devel at lists.osgeo.org> 
> https://lists.osgeo.org/mailman/listinfo/postgis-devel

_______________________________________________
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

_______________________________________________
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/20170905/3f20ecec/attachment.html>