agora inbox for pgsql-hackers@postgresql.org
help / color / mirror / Atom feedFrom: Sandro Santilli <strk@kbt.io>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: Regina Obe <lr@pcorp.us>
Cc: pgsql-hackers@postgresql.org
Subject: Re: [PATCH] Support % wildcard in extension upgrade filenames
Date: Sat, 4 Jun 2022 11:26:19 +0200
Message-ID: <YpslO13vull+7cWv@c19> (raw)
In-Reply-To: <3069230.1653752250@sss.pgh.pa.us>
References: <YgakFklJyM5pNdt+@c19>
<001d01d87211$edbd5b50$c93811f0$@pcorp.us>
<d3924670ba8fefa42f4bd462c5b7f6349d63f4d3.camel@cybertec.at>
<3069230.1653752250@sss.pgh.pa.us>
On Sat, May 28, 2022 at 11:37:30AM -0400, Tom Lane wrote:
> Laurenz Albe <laurenz.albe@cybertec.at> writes:
> > 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?
> > Having a lower bound for a matching version might be a good idea,
> > although I have no idea how to do that.
>
> The lack of upper bound is a problem too: what stops the system from
> trying to use this to get from (say) 4.2 to 3.3, and if it does try that,
> will the script produce a sane result?
This is a very old problem we had before EXTENSION was even available
in PostgreSQL, and so we solved this internally. The upgrade script
for PostGIS checks the version of the existing code and refuses to
downgrade (and refuses to upgrade if a dump/restore is required).
> I'm frankly skeptical that this is a good idea at all. It seems
> to have come out of someone's willful refusal to use the system as
> designed, ie as a series of small upgrade scripts that each do just
> one step. I don't feel an urgent need to cater to the
> one-monster-script-that-handles-all-cases approach, because no one
> has offered any evidence that that's really a better way. How would
> you even write the conditional logic needed ... plpgsql DO blocks?
> Testing what? IIRC we don't expose any explicit knowledge of the
> old extension version number to the script.
We (PostGIS) do expose explicit knowledge of the old extension, and
for this reason I think the pattern-based logic should be
enabled explicitly in the postgis.control file. It could be even less
generic and more specific to a given extension need, if done
completely inside the control file. For PostGIS all we need at the
moment is something like (in the control file):
one_monster_upgrade_script = postgis--ANY--3.3.0.sql
--strk;
view thread (78+ messages) latest in thread
Message-ID: <YpslO13vull+7cWv@c19>
Permalink: ../YpslO13vull+7cWv@c19/
Also on: postgresql.org/message-id/YpslO13vull+7cWv@c19
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: pgsql-hackers@postgresql.org
Cc: strk@kbt.io, tgl@sss.pgh.pa.us, laurenz.albe@cybertec.at, lr@pcorp.us
Subject: Re: [PATCH] Support % wildcard in extension upgrade filenames
In-Reply-To: <YpslO13vull+7cWv@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