From: Sandro Santilli <strk@kbt.io>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Regina Obe <r@pcorp.us>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: [PATCH] Support % wildcard in extension upgrade filenames
Date: Wed, 11 Jan 2023 11:10:40 +0100
Message-ID: <20230111101040.ovihmu4rssefut2o@c19> (raw)
In-Reply-To: <387183.1673394631@sss.pgh.pa.us>
References: <YgakFklJyM5pNdt+@c19>
<20221117095734.igldlk6kngr6ogim@c19>
<166914379479.1121.7549798686571352890.pgcf@coridan.postgresql.org>
<55512.1673304709@sss.pgh.pa.us>
<20230110205259.htcuhg3t7shd367d@c19>
<387183.1673394631@sss.pgh.pa.us>
On Tue, Jan 10, 2023 at 06:50:31PM -0500, Tom Lane wrote:
> With the proposed % feature, if foo--%--3.0.sql exists then the
> system will invoke it and expect the end result to be a valid
> 3.0 installation, whether or not the script actually has any
> ability to do a downgrade.
It is sane, for the system to expect the end result
to be a valid 3.0 installation if no exception is
thrown by the script itself.
If we ship foo--%--3.0.sql we must have been taken care of
protecting from unsupported downgrades/upgrades (and we did,
having the script throw an exception if anything is unexpected).
> (I suppose you could add code to look at pg_extension.extversion,
We actually added code looking at our own version-extracting
function (which existed since before PostgreSQL added support
for extensions). Is the function not there ? Raise an exception.
Is the function not owned by the extension ? Raise an exception.
In other cases -> trust the output of that function to tell what
version we're coming from, throw an exception if upgrade to the
target version is unsupported.
> to add such code is that really better than having a number of
> one-liner scripts implementing the same check declaratively?)
Yes, it is, because no matter how many one-liner scripts we install
(we currently install 87 * 6 such scripts, we always end up missing
some of them upon releasing a new bug-fix release in stable branches.
> almost certainly you are
> going to end with an extension containing some leftover 4.0
> objects, some 3.0 objects, and maybe some objects with properties
> that don't exactly match either 3.0 or 4.0.
This is already possible, depending on WHO writes those upgrade
scripts. This proposal just gives more expressiveness power to
those script authors.
> So I really think this is a case of "be careful what you ask
> for, you might get it". Even if PostGIS is willing to put in
> the amount of infrastructure legwork needed to make such a
> design bulletproof, I'm quite sure nobody else will manage
> to use such a thing successfully.
This is why I initially made this something to be explicitly enabled
by the .control file, which I can do again if it feels safer for you.
> I'd rather spend our
> development effort on a feature that has more than one use-case.
Use case is any extension willing to support more than a single stable
branch while still allowing upgrading from newer-stable-bugfix-release
to older-feature-release (ie: 3.2.10 -> 3.4.0 ). Does not seem so
uncommon to me, for a big project. Maybe there aren't enough big
extension-based projects out there ?
--strk;
Libre GIS consultant/developer
https://strk.kbt.io/services.html
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, r@pcorp.us, pgsql-hackers@lists.postgresql.org
Subject: Re: [PATCH] Support % wildcard in extension upgrade filenames
In-Reply-To: <20230111101040.ovihmu4rssefut2o@c19>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox