I want to chime in on the issue of lower-number releases that are released after higher-number releases. The way I see this particular problem is that we always put upgrade SQL files in release "packages," and they obviously become static resources.
While I [intentionally] overlook some details here, what if (as a convention, for projects where it matters) we shipped extensions with non-upgrade SQL files only, and upgrades were available as separate downloads? This way, we're not tying releases themselves to upgrade paths. This also requires no changes to Postgres. I know this may be a big delivery layout departure for well-established projects; I also understand that this won't solve the problem of having to have these files in the first place (though in many cases, they can be automatically generated once, I suppose, if they are trivial). On Tue, Jan 10, 2023 at 5:52 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > 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 > > > -- Y.
