> On Mon, Apr 03, 2023 at 09:26:25AM +0700, Yurii Rashkovskii wrote: > > 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. > > This is actually something that's on the plate, and we recently added a -- > disable-extension-upgrades-install configure switch and a `install-extension- > upgrades-from-known-versions` make target in PostGIS to help going in that > direction. I guess the ball would now be in the hands of packagers. > > > 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). > > We will now also be providing a `postgis` script for administration that among > other things will support a `install-extension-upgrades` command to install > upgrade paths from specific old versions, but will not hard-code any list of > "known" old versions as such a list will easily become outdated. > > Note that all upgrade scripts installed by the Makefile target or by the > `postgis` scripts will only be empty upgrade paths from the source version to > the fake "ANY" version, as the ANY--<current> upgrade path will still be the > "catch-all" upgrade script. > > --strk; >
Sounds like a user and packaging nightmare to me. How is a packager to know which versions a user might have installed? and leaving that to users to run an extra command sounds painful. They barely know how to run ALTER EXTENSION postgis UPDATE; Or pg_upgrade I much preferred the idea of just listing all our upgrade targets in the control file. The many annoyance I have left is the 1000 of files that seem to grow forever. This isn't just postgis. It's pgRouting, it's h3_pg, it's mobilitydb. I don't want to have to set this up for every single extension that does micro-updates. I just want a single file that can list all the target paths worst case. We need to come up with a convention of how to describe a micro update, as it's really a problem with extensions that follow the pattern major.minor.micro In almost all cases the minor upgrade script works for all micros of that minor and in postgis yes we have a single script that works for all cases. Thanks, Regina
