Re: [PATCH] Support % wildcard in extension upgrade filenames

public inbox for [email protected]  
help / color / mirror / Atom feed

From: Sandro Santilli <[email protected]>
To: Regina Obe <[email protected]>
Cc: 'Yurii Rashkovskii' <[email protected]>
Cc: 'Tom Lane' <[email protected]>
Cc: 'Regina Obe' <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH] Support % wildcard in extension upgrade filenames
Date: Tue, 11 Apr 2023 20:48:23 +0200
Message-ID: <20230411184823.s3cctaf63qvfeqlj@c19> (raw)
In-Reply-To: <[email protected]>
References: <YgakFklJyM5pNdt+@c19>
	<20221117095734.igldlk6kngr6ogim@c19>
	<166914379479.1121.7549798686571352890.pgcf@coridan.postgresql.org>
	<[email protected]>
	<CA+RLCQwWpMuKtqg7eBOjvzpJc-hE708WpHG2=z5B969xncQS3w@mail.gmail.com>
	<20230409204629.sf4fptx672iehcau@c19>
	<[email protected]>

On Mon, Apr 10, 2023 at 11:09:40PM -0400, Regina Obe wrote:
> > 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.
> 
> Sounds like a user and packaging nightmare to me.
> How is a packager to know which versions a user might have installed?

Isn't this EXACTLY the same problem WE have ? The problem is we cannot
know in advance how many patch-level releases will come out, and we
don't want to hurry into cutting a new release in branches NOT having
a bug which was fixed in a stable branch...

Packager might actually know better in that they could ONLY consider
the packages ever packaged by them.

Hey, best would be having support for wildcard wouldn't it ? 

> I much preferred the idea of just listing all our upgrade targets in the control file.

Again: how would we know all upgrade targets ?

> 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

I think it's a problem with extensions maintaining stable branches,
as if the history was linear we would possibly need less files
(although at this stage any number bigger than 1 would be too much for me)

--strk;

view thread (21+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: [PATCH] Support % wildcard in extension upgrade filenames
  In-Reply-To: <20230411184823.s3cctaf63qvfeqlj@c19>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox