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).
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
--
