Remove Micro (Patch level) from our extension scripts and use 0-byte scripts

[robe]

This will be for PostGIS 3.3.0 moving forward. We discussed the idea of doing that for all minors, but decided that was too drastic.

Main benefits:

1) We will eventually have fewer files (savings of not having micro scripts moving forward) Note even if PostgreSQL project were to fix this, we'd still need something like this for older versions of PostgreSQL since they likely will not backport that.

2) Using Paul's 0 byte, the file sizes will be smaller even if the packager doesn't symlink.

3) If someone is upgrading from a version released after the one they are upgrading to, they can still upgrade. It also means we don't need to have to remember to include recently released micros in our new release.

So sadly we've still got to carry all those scripts.

3.3 will have scripts

# these all 0 byte
 postgis--3.0.0--3.3.MAX.sql
 postgis--3.0.1--3.3.MAX.sql
 :
 postgis--3.1.0--3.3.MAX.sql 
 postgis--3.1.1--3.3.MAX.sql
 postgis--3.1.2--3.3.MAX.sql
:
:
postgis--3.2.1--3.3.MAX.sql
postgis--3.3.0alpha1--3.3.MAX.sql
postgis--3.3.0dev--3.3.MAX.sql

# these not 0 byte
postgis--3.3.MAX--3.3.sql 
postgis-3.3next--3.3.sql
postgis-3.3--3.3next.sql

(the 3.3next 3.3.sql I am thinking if we decided we want our alter extension scripts to have CREATE OR REPLACE only for existing and CREATE for net-net new, we'd still keep the CREATE OR REPLACE for the 3.3next even for net-net new and for the 3.3X--3.3.sql this would be CREATE for net-net new functionality.

and so most we will use 0 byte files as Paul proposed here - ​https://trac.osgeo.org/postgis/wiki/PostGISExtensionPaths#SOLUTION3

postgis 3.4 would then look like

# these all 0 byte
 postgis--3.0.0--3.3.MAX.sql
 :
 postgis--3.1.0--3.4.MAX.sql 
 postgis--3.1.1--3.4.MAX.sql
 postgis--3.1.2--3.4.MAX.sql
:
:
postgis--3.2.1--3.4.MAX.sql
postgis--3.3--3.4.MAX.sql #regardless which 3.3 micro release, no new files

# these not 0 byte
postgis--3.4.MAX--3.4.sql 
postgis-3.4next--3.4.sql 
postgis-3.4-3.4next.sql

[strk]

Is there a typo in the original description of this ticket ? I don't understand the postgis--3.0 line, and I see spaces before the --3.4.X.sql which I'm not sure how to interpret.

Also, I think Paul idea was to have upgrade scripts look like:

`postgis-3.1.1--3.1.MAX.sql' or similar ?

I don't see the benefit of having an upgrade path called 3.3.X--3.3.0 otherwise (would look like being open for downgrades) ?

How does this simplify things ? What problem does it solve ?

[robe]

Replying to strk:

Is there a typo in the original description of this ticket ? I don't understand the postgis--3.0 line, and I see spaces before the --3.4.X.sql which I'm not sure how to interpret.

Yes

Also, I think Paul idea was to have upgrade scripts look like:

`postgis-3.1.1--3.1.MAX.sql' or similar ?

I don't see the benefit of having an upgrade path called 3.3.X--3.3.0 otherwise (would look like being open for downgrades) ?

Fixed

How does this simplify things ? What problem does it solve ?

It simplifies things because:

1) We will eventually have fewer files (savings of not having micro scripts moving forward) Note even if PostgreSQL project were to fix this, we'd still need something like this for older versions of PostgreSQL since they likely will not backport that.

2) Using Paul's 0 byte, the file sizes will be smaller even if the packager doesn't symlink.

[robe]

Enough disgruntled PSC to make this not happen.