"Regina Obe" <l...@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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers