> I continue to think that this is a fundamentally bad idea. It creates all
sorts of
> uncertainties about what is a valid update path and what is not.
Restrictions
> like
>
> + Such wildcard update
> + scripts will only be used when no explicit path is found from
> + old to target version.
>
> are just band-aids to try to cover up the worst problems.
>
> Have you considered the idea of instead inventing a "\include" facility
for
> extension scripts? Then, if you want to use one-monster-script to handle
> different upgrade cases, you still need one script file for each supported
> upgrade step, but those can be one-liners including the common script
file.
> Plus, such a facility could be of use to people who want intermediate
> factorization solutions (that is, some sharing of code without buying all
the
> way into one-monster-script).
>
> regards, tom lane
The problem with an include is that it does nothing for us. We still need to
ship a ton of script files. We've already dealt with the file size issue.
So our PostGIS 3.4.0+ (not yet released) already kind of simulates include
using blank script files that have nothing in them but forces the extension
machinery to upgrade the version to ANY to get to the required installed
version 3.4.0+
So for example postgis--3.3.0--ANY.sql
Would contain this:
-- Just tag extension postgis version as "ANY"
-- Installed by postgis 3.4.0dev
-- Built on ...
And the file has the upgrade steps:
postgis--ANY--3.4.0dev.sql
So that when you are on 3.3.0 and want to upgrade to 3.4.0dev ( it takes
3.3.0 -> ANY -> 3.4.0dev)
The other option I had proposed was getting rid of the micro version, but I
got shot down on that argument -- with PostGIS PSC complaining about people
not being able to upgrade a micro if per chance we have some security patch
released in a micro.
https://lists.osgeo.org/pipermail/postgis-devel/2022-June/029673.html
https://lists.osgeo.org/pipermail/postgis-devel/2022-July/029713.html
Thanks,
Regina