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

[Stephen Frost]

Mark, all,

* Mark Cave-Ayland (mark.cave-ayland at ilande.co.uk) wrote:
> On 29/08/17 14:57, Sandro Santilli wrote:
> 
> > On Tue, Aug 29, 2017 at 09:33:34AM -0400, Stephen Frost wrote:
> > 
> >> Perhaps we can improve the upgrade process by warning users ahead of
> >> time in a nicer way than the error pg_upgrade throws today, but I'm not
> >> sure what that would really look like.
> > 
> > I wonder if `pg_upgrade` itself could get a switch added to
> > automatically upgrade extensions, maybe something to be called
> > specified in the extension's control file...
> 
> Right so just to clarify - the primary issue is that pg_upgrade fails
> when upgrading both PostgreSQL and PostGIS? Do the CREATE FUNCTION
> definitions make it through the upgrade, and so it's just the lack of
> the old shared library that causes the problem?
> 
> But yes, I believe this is more along the lines that we should be thinking.

What I've generally seen is that pg_upgrade will complain if the new
cluster doesn't have the same .so file that the old one does, because if
that's the case then the functions defined in the database will stop
working post-upgrade.

That is, if you have 9.4 + 2.2 and 9.5 + 2.3, pg_upgrade will refuse to
run because it's looking in the 9.5 version for the 2.2 .so file and not
finding it.  Users have to first upgrade to 9.4 + 2.3 and then run
pg_upgrade to get to 9.5 + 2.3.

If, in reality, the 2.3 .so file will work just fine with the 2.2
function definitions and symbols and there haven't been any ABI breaks
in those existing functions, then this is entirely unnecessary and just
causing undo pain for users.

Thanks!

Stephen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20170830/5235d5c6/attachment.sig>