[postgis-devel] Upgrade strategies (was: PSC Vote: Get rid of micro in PostGIS Extension scripts)

[Sandro Santilli]

On Wed, Jun 08, 2022 at 01:06:02PM -0400, Regina Obe wrote:
> Sandro wrote:
> 
> > I find the naming confusing, wouldn't this be clearer if it was:
> > 
> >   postgis--3.0.0--ANY.sql (0 bytes)
> >   postgis--ANY--3.3.0.sql (real upgrade)
> > 
> > We'd then be moving along the same track we are already on
> 
> I'm fine with that change. Only minor issues I see with this is:
> 
> 1) postgis-3.0.0--ANY.sql and friends will be carried by both 3.3.0 and
> 3.4.0 releases.  Debian might have issue with this since I think they
> package the scripts in a separate package.  But at least the files will all
> be the same.

Ah yes, now I remember why Paul came up with the other idea
of an "MAX" per-branch version:

  postgis-3.0.0--3.0.MAX.sql
  postgis-3.0.MAX--ANY.sql

But it would still have the same problem, when upgrading to 3.0.1, right ?
Or is Paul proposal taking care of this issue ?

> 2) It leads one to believe that they can downgrade, though I think our
> plumbing might already take care of this.

Yes, this is already the case and yes we have checks to prevent this.
It's already possible, via `postgis_extensions_upgrade()` to actually
attempt to downgrade, if the "default" version of PostGIS (latest
version installed) is older than the currently installed version.

We might add automated testcases checking that the user gets an error
message when attempting that, but it would be easier to write such
test if we made `postgis_extensions_upgrade()` accept a target
version, as described in https://trac.osgeo.org/postgis/ticket/5052

--strk; 

  Libre GIS consultant/developer
  https://strk.kbt.io/services.html