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

[Paul Ramsey]

Yes, certainly seems like interim measure #1 is to carefully document what
a pg_upgrade upgrade looks like and it's one of

- install newest postgis in your old postgresql, ALTER EXTENSION to upgrade
to that
- install new postgresql version and newest postgis in that, do the
pg_upgrade
- you're done

or

- install new postgresql version and your current version of postgis in
that, do the pg_upgrade
- install newest postgis, ALTER EXTENSION to upgrade to that, you're done
- you're done

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


On Tue, Sep 5, 2017 at 1:13 AM, Sandro Santilli <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 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
> 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/844de681/attachment.html>