Stop filling up the disk with upgrade scripts

[strk]

They are really too much:

[strk@c19:~] ls `pg_config --sharedir`/extension/postgis* | wc -l
1922

And mine is a relatively new machine.

This ticket is a placeholder to bring the idea of having a single, unique upgrade script (one per *target*) upstream to PostgreSQL.

We're effectively having such single file upgrade since forever (before EXTENSION even existed).

Starting with commit [cff01033637ddcf984d12edbbecc9f70b0e4de4e/git] (3.3.0dev) the postgis_extensions_upgrade() effectively makes the ANY--<target> extension file the ONLY file required for the upgrade.

The loader/postgis script already did this as of commit [8ab82431e5b080ee0f65810afecd9028e2bc3744/git] (3.1).

We started installing that file with commit [04e8d00d8b55df69705c316fb2feecce23a29bfc/git] (2.5)

[strk]

Proposal was sent to PostgreSQL to support wildcards on upgrade scripts: ​https://www.postgresql.org/message-id/YgakFklJyM5pNdt%2B%40c19

PostGIS Devel mailing list proposal: ​https://lists.osgeo.org/pipermail/postgis-devel/2022-February/029500.html

[robe]

@strk just added it to PostgreSQL commitfest and I have made myself a reviewer

​https://commitfest.postgresql.org/38/3654/

It's too late for PG15, but we can shoot for PG16

[robe]

related trac ticket discussion

​https://trac.osgeo.org/postgis/wiki/PostGISExtensionPaths

[Sandro Santilli <strk@…>]

In 984383d/git:

Refactor extension upgrade mechanism

Install <version>—ANY upgrade paths

These <extension>—<version>—ANY.sql upgrade files will be symlinks
( or copies, on systems not supporting symlinks ) to an empty upgrade
template file named <extension>—TEMPLATED—TO—ANY.sql and be
overwritten by any future versions of PostGIS, keeping the overall
number of upgrade paths down ( see #5092 )

Presence of these upgrade paths will allow ALTER EXTENSION going
from any version to any other version by stepping by the fake "ANY"
version. This allows us to stop updating pg_extension table,
fixing #5194 in a more generic way.

Stop installing the "<version>—<version>next" and
"<version>next—<version>" as the same thing can be done by stepping
by the "ANY" version. Update run_test.pl script accordingly to use
ANY instead of "next" for self-upgrading newer PostGIS

Add support for installing missing upgrade paths in the postgis
commandline, to allow upgrading from newly-released stable branches
to previously-released feature branches.

Include NEWS entries

[strk]

I'd be happy to close this out once the install-extension-upgrades-from-known-versions make target stops being run by default when install is run …

[Sandro Santilli <strk@…>]

In dfb471d/git:

Add —disable-extension-upgrades-install configure switch

The switch disables automatic install of extension upgrade
scripts, giving a message at the end of make install as to
how to manually deal with those.

References #5092

[strk]

New upstream commitfest item is in here: ​https://commitfest.postgresql.org/44/4489/