[postgis-devel] PSC Vote: Get rid of micro in PostGIS Extension scripts (and comments from others)

[Sandro Santilli]

On Mon, Jun 06, 2022 at 05:09:33PM +0300, Дорофей Пролесковский wrote:

> If we're going to do something about it I believe it should be a thing
> bringing the version model closer to the Postgres intended one, where diffs
> are being generated or scripts are getting constructed in form of a
> DAG/chain of version migrations. This can also help fix the issue of extra
> features in newer PG for the same PostGIS, if we bake the PG version into
> the extension version - which differs really between PG versions.

How would the chain-of-diffs deal with our multi-branch mantaintance ?

Use case:

  User A installs 3.0.1, then upgrades to 3.3.0. Both installed from packages.

Which scripts would be installed on user A system ?

> Maybe what we need is a bit more indirection on the PG side - if we can
> have a table that lists all the upgrade scripts and the version pair will
> be a part of the table and filename can be arbitrary - then there won't be
> a problem of duplicated files on the filesystem. Maybe a way to register
> aliases as not to break the currently working way.

At the moment PostgreSQL *derives* that indirection table from filenames.
The idea behind my patch is to use filenames to express wider validity
of upgrade scripts (starting from the "from ANY" concept, which is
currently the only thing we need).

> A thing to look at: Postgres now has stored procedures that exist outside
> transactions, may happen that calling one will fix the problem with running
> postgis_extensions_upgrade() - we can do that twice internally.

Yes, this is a good idea, supported from PostgreSQL version 11, so the
master branch of PostGIS, which already requires that version as a
minimum, could start using stored procedure. Would you be up to file
a ticket to do so ?

--strk;