From: "Regina Obe" <lr@pcorp.us>
To: <strk@kbt.io>,
	"'Yurii Rashkovskii'" <yrashk@gmail.com>
Cc: "'Tom Lane'" <tgl@sss.pgh.pa.us>,
	"'Regina Obe'" <r@pcorp.us>,
	<pgsql-hackers@lists.postgresql.org>
References: <YgakFklJyM5pNdt+@c19> <20221117095734.igldlk6kngr6ogim@c19> <166914379479.1121.7549798686571352890.pgcf@coridan.postgresql.org> <55512.1673304709@sss.pgh.pa.us> <CA+RLCQwWpMuKtqg7eBOjvzpJc-hE708WpHG2=z5B969xncQS3w@mail.gmail.com> <20230409204629.sf4fptx672iehcau@c19>
In-Reply-To: <20230409204629.sf4fptx672iehcau@c19>
Subject: RE: [PATCH] Support % wildcard in extension upgrade filenames
Date: Mon, 10 Apr 2023 23:09:40 -0400
Message-ID: <000501d96c23$0f05bdf0$2d1139d0$@pcorp.us>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQGYmaaUCwtlrmE55CHyCSUXu9VHkgKopfE4AVtxnv8DArAuyQGfbhARAm8A8U6vTmV1YA==
Content-Language: en-us
Archived-At: <https://www.postgresql.org/message-id/000501d96c23%240f05bdf0%242d1139d0%24%40pcorp.us>
Precedence: bulk

> 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.
>=20
> 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.
>=20
> > 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).
>=20
> 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.
>=20
> 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.
>=20
> --strk;
>=20

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


=20