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

From: "Regina Obe" <lr(at)pcorp(dot)us>
To: <strk(at)kbt(dot)io>, "'Robert Haas'" <robertmhaas(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-03-13 18:48:56
Message-ID: 003201d955dc$7770af60$66520e20$
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> > I wonder if a solution to this problem might be to provide some kind
> > of a version map file. Let's suppose that the map file is a bunch of
> > lines of the form X Y Z, where X, Y, and Z are version numbers. The
> > semantics could be: we (the extension authors) promise that if you
> > want to upgrade from X to Z, it suffices to run the script that knows
> > how to upgrade from Y to Z.
> > This would address Tom's concern, because if you write a master
> > upgrade script, you have to explicitly declare the versions to which
> > it applies.
> This would just move the problem from having 1968 files to having to write
> 1968 lines in control files,

1968 lines in one control file, is still much nicer than 1968 files in my
From a packaging standpoint also much cleaner, as that single file gets
replaced with each upgrade and no need to uninstall more junk from prior

> We maintain multiple stable branches (5, at the moment: 2.5, 3.0, 3.1,
> 3.3) and would like to allow anyone running an old patched version to
> upgrade to a newer version released earlier.
> --strk;
> Libre GIS consultant/developer

That said, I really would like a wildcard option for issues strk mentioned.

I still see the main use-case as for those that micro version and for this
use case, they would need a way, not necessarily to have a single upgrade
script, but a script for each minor.

So something like

3.2.%--3.4.0 = 3.2--3.4.0

In many cases, they don't even need anything done in an upgrade step, aside
from moving the dial button on extension up a notch to coincide with the lib

In our case, yes ours would be below because we already block downgrades
internally in our scripts

%--3.4.0 = ANY--3.4.0

Or we could move to a

2.%--3.4.0 = 2--3.4.0
3.%--3.4.0 = 3--3.4.0


In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Nazir Bilal Yavuz 2023-03-13 18:57:22 Re: meson: Non-feature feature options
Previous Message Nathan Bossart 2023-03-13 18:21:47 Re: Reducing connection overhead in pg_upgrade compat check phase