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

[Regina Obe]

> It's not many steps, frankly. The "only" reason this is hard for casual users is because we almost always lack the "old postgis, new postgresql" or "old postgresql, new postgis" combination in packaging. We > could start begging packagers to cover those combos, if the pg_upgrade use case is a killer features (probably is)

 

> P

You underestimate the level of effort involved in doing that on both part of PostGIS to support old versions on newer versions, PostgreSQL packagers having to maintain multiple postgis versions on same PostgreSQL.  

What if a user wants to pg_upgrade from 9.4 to 10?  Then what.  They have to first upgrade to 9.5 then upgrade their postgis then upgrade to 9.6 then upgrade their postgis yadda yadda.

That happens all the time.

 

You guys should just listen to Tom and do the right thing.  I'm thru arguing with all of you.  Do what you want.

 

Thanks,

Regina

 

 

On Tue, Sep 5, 2017 at 1:13 AM, Sandro Santilli <strk at kbt.io <mailto:strk at kbt.io> > wrote:

On Tue, Sep 05, 2017 at 09:17:36AM +0200, Sandro Santilli wrote:
> On Mon, Sep 04, 2017 at 10:12:00PM +0100, Mark Cave-Ayland wrote:
>
> > The other particularly evil thought that occurred to me was do you need
> > to have a real PostGIS 2.3? What if you were to generate a compatibility
> > postgis-2.3.so <http://postgis-2.3.so>  with empty stub methods - would that be enough to be able
> > to remove the extension post-upgrade and then install the new version?
>
> The ALTER EXTENSION itself makes a single call to a function
> referencing the shared object and already handles an exception
> so it should work.
>
> But generating a compatibility layer seems more work than just
> keeping the old signatures in the new code...

I've conducted an experiment to find out much of a dirty hack we'd
need to provide something working for pg_upgrade.

1) The tool explicitly tests for the referenced libraries to exist
   and be loadable (touching  a .so does not help, symlinking to
   an arbitrary one does)

2) The tool ends up using pg_dump/pg_restore but does not have a
   CREATE EXTENSION in the dump !


For comparison, this is what you find in the dump created by pg_dump:

        CREATE EXTENSION IF NOT EXISTS postgis WITH SCHEMA public;

While this is what you find in the dump created by pg_upgrade:

        -- For binary upgrade, create an empty extension and insert objects into it
        DROP EXTENSION IF EXISTS "postgis";
        SELECT pg_catalog.binary_upgrade_create_empty_extension('postgis', 'public', false, '2.4.0dev', '{16684}', '{"WHERE NOT (...

I'm not sure what's the benefit of pg_upgrade, but it's clearly threating
extensions in a different way from pg_dump. Specifically, in a way that
breaks the "EXTENSION will result in easier upgrades" dream...

To recap (this would be best added in the "upgrade" documentation of postgis):

 - When upgrading from a PostgreSQL version to another, it's best to
   follow the already documented "hard upgrade" procedure, as it takes
   care of everything.

 - If willing to use pg_upgrade (I dunno why would you want that) then
   make sure to have the *exact_same* version of PostGIS available in
   the target PostgreSQL version (will need a rebuild)


--strk;


_______________________________________________
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/a1f0ef2a/attachment.html>