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

Sandro Santilli strk at kbt.io
Tue Sep 5 01:13:51 PDT 2017


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;
  




More information about the postgis-devel mailing list