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

[Regina Obe]

Given this is not a trivial decision, I want to make sure no one has
reservations that can't be addressed.
That includes non-PSC.

+1 from me.

Detailed here (sorry I had the subject part wrong initially)

https://trac.osgeo.org/postgis/ticket/5166

This will be for PostGIS 3.3.0 onward (we'd still need to track all those
old files from previous versions, annoying)

Benefits:

1) Fewer extension files piling up moving forward
2) Not having this annoyance of remembering to add the latest micro (at
least for 3.3, will be useful for 3.4) moving forward.

Cons:
1) Doing micro SQL API changes will be harder, and so should be avoided. We
don't do that many of those anyway aside from security patches.
2) Nothing will happen if people do 

ALTER EXTENSION postgis UPDATE;  

If they are already on latest minor.  We've had this issue all along by the
way (even for micros)  for cases where people pg_upgrade from say 3.2.1 on
PG 11 to 3.2.1 on PG 14, because extension system doesn't recognize the idea
that a particular extension version might have extra features enabled for
newer versions of PostgreSQL.

However I think this can all be mitigated, for folks trained to use: 

SELECT postgis_extensions_upgrade();  

strk -- I haven't checked, but I think you had changed this to work if the
PostgreSQL version script is different from the current PostgreSQL version.
If not we need to fix that anyway.

We could also add a force or an explicit PostGIS version arg to that which
we would need for development upgrades and when such a version is passed it
will force upgrade using next or ANY hack.

The force way should avoid touching system tables, since DBaaS won't allow
it, but I think doing a yoyo dance (next -> back to where we were) works
fine.