> 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
