"Regina Obe" <lr@pcorp.us> writes:
> I think this thread covers most of the issues.
> https://lists.osgeo.org/pipermail/postgis-devel/2017-August/026355.html
> My thought was is it possible for pg_upgrade to be taught to use CREATE
> EXENSION if asked?
We intentionally *don't* do that; pg_dump goes to a lot of trouble to
duplicate the old extension contents exactly, instead. There are a bunch
of corner cases that would fail if we allowed the new installation to
have different extension contents than the old. Believe you me, we'd
rather have just issued CREATE EXTENSION, but it doesn't work.
Looking quickly at the thread you cite, I wonder how much of this problem
is caused by including version numbers in the library's .so filename.
Have you considered not doing that? Our experience with maintaining the
contrib modules is that it's easier to attach a version number to an
individual function (in its C name, where it's irrelevant to SQL users).
If you incompatibly upgrade a given function, you can leave a stub behind,
with the old C symbol, that does nothing but throw an error if called.
Or you can keep on supporting the old API if it's easy enough; it
doesn't have to be a library-wide decision.
> My solution of let's not call it postgis-2.4 but just postgis-2 from
> thenceforward for the life of 2 major series because we don't break backward
> compatibility often in a PostGIS minor version got shot down.
The thread you mention doesn't seem to include any arguments why not
to do that.
regards, tom lane
