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

From: Sandro Santilli <strk(at)kbt(dot)io>
To: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
Cc: Regina Obe <lr(at)pcorp(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] Support % wildcard in extension upgrade filenames
Date: 2022-06-04 09:20:55
Message-ID: Ypsj95RJSARwfQt6@c19
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Sat, May 28, 2022 at 04:50:20PM +0200, Laurenz Albe wrote:
> On Fri, 2022-05-27 at 17:37 -0400, Regina Obe wrote:
> >
> >
> >
> > Does anyone think this is such a horrible idea that we should abandon all
> > hope?
> I don't think this idea is fundamentally wrong, but I have two worries:
> 1. It would be a good idea good to make sure that there is not both
> "extension--%--2.0.sql" and "extension--1.0--2.0.sql" present.
> Otherwise the behavior might be indeterministic.

I'd make sure to use extension--1.0--2.0.sql in that case (more
specific first).

> 2. What if you have a "postgis--%--3.3.sql", and somebody tries to upgrade
> their PostGIS 1.1 installation with it? Would that work?

For PostGIS in particular it will NOT work as the PostGIS upgrade
script checks for the older version and decides if the upgrade is
valid or not. This is the same upgrade code used for non-extension

> Having a lower bound for a matching version might be a good idea,
> although I have no idea how to do that.

I was thinking of a broader pattern matching support, like:


But it would be better to start simple and eventually if needed
increase the complexity ?

Another option could be specifying something in the control file,
which would also probably be a good idea to still allow some
extensions to use '%' in the version string (for example).


Libre GIS consultant/developer

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Sandro Santilli 2022-06-04 09:21:53 Re: [PATCH] Support % wildcard in extension upgrade filenames
Previous Message Michael Paquier 2022-06-04 03:35:45 Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set