|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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
> 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
|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|