From: | "Regina Obe" <lr(at)pcorp(dot)us> |
---|---|
To: | <strk(at)kbt(dot)io>, "'Yurii Rashkovskii'" <yrashk(at)gmail(dot)com> |
Cc: | "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "'Regina Obe'" <r(at)pcorp(dot)us>, <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | RE: [PATCH] Support % wildcard in extension upgrade filenames |
Date: | 2023-04-11 03:09:40 |
Message-ID: | 000501d96c23$0f05bdf0$2d1139d0$@pcorp.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Andy Fan | 2023-04-11 03:43:27 | Re: Can we rely on the ordering of paths in pathlist? |
Previous Message | Richard Guo | 2023-04-11 03:03:27 | Can we rely on the ordering of paths in pathlist? |