[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