Date: Thu, 15 Sep 2022 00:02:49 +0200
From: Sandro Santilli <strk@kbt.io>
Sender: strk@kbt.io
To: pgsql-hackers@postgresql.org, Laurenz Albe <laurenz.albe@cybertec.at>,
	Regina Obe <lr@pcorp.us>, Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: [PATCH] Support % wildcard in extension upgrade filenames
Message-ID: <YyJPicrQVVXOs2QE@c19>
Mail-Followup-To: Sandro Santilli <strk@kbt.io>,
	pgsql-hackers@postgresql.org,
	Laurenz Albe <laurenz.albe@cybertec.at>, Regina Obe <lr@pcorp.us>,
	Tom Lane <tgl@sss.pgh.pa.us>
References: <YgakFklJyM5pNdt+@c19>
 <001d01d87211$edbd5b50$c93811f0$@pcorp.us>
 <d3924670ba8fefa42f4bd462c5b7f6349d63f4d3.camel@cybertec.at>
 <Ypsj95RJSARwfQt6@c19>
 <YyJPHOfwLIjxxi9u@c19>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="339zka8KxudZ+6RE"
Content-Disposition: inline
In-Reply-To: <YyJPHOfwLIjxxi9u@c19>
Archived-At: <https://www.postgresql.org/message-id/YyJPicrQVVXOs2QE%40c19>
Precedence: bulk


--339zka8KxudZ+6RE
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

And now with the actual patch attached ... (sorry)

--strk;

On Thu, Sep 15, 2022 at 12:01:04AM +0200, Sandro Santilli wrote:
> I'm attaching an updated version of the patch. This time the patch
> is tested. Nothing changes unless the .control file for the subject
> extension doesn't have a "wildcard_upgrades = true" statement.
> 
> When wildcard upgrades are enabled, a file with a "%" symbol as
> the "source" part of the upgrade path will match any version and
> will be used if a specific version upgrade does not exist.
> This means that in presence of the following files:
> 
>     postgis--3.0.0--3.2.0.sql
>     postgis--%--3.2.0.sql
> 
> The first one will be used for going from 3.0.0 to 3.2.0.
> 
> This is the intention. The patch lacks automated tests and can
> probably be improved.
> 
> For more context, a previous (non-working) version of this patch was
> submitted to commitfest: https://commitfest.postgresql.org/38/3654/
> 
> --strk;
> 
> On Sat, Jun 04, 2022 at 11:20:55AM +0200, Sandro Santilli wrote:
> > 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:
> > > >
> > > > https://lists.osgeo.org/pipermail/postgis-devel/2022-February/029500.html
> > > > 
> > > > 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
> > installs.
> > 
> > >    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:
> > 
> >   postgis--3.%--3.3.sql
> > 
> > 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).
> > 
> > --strk; 

--339zka8KxudZ+6RE
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
	filename="v2-0001-Allow-wildcard-in-extension-upgrade-paths.patch"