Date: Thu, 27 Apr 2023 12:49:57 +0200
From: Sandro Santilli <strk@kbt.io>
Sender: strk@kbt.io
To: Mat Arye <mat@timescaledb.com>
Cc: Regina Obe <lr@pcorp.us>, Yurii Rashkovskii <yrashk@gmail.com>,
	Tom Lane <tgl@sss.pgh.pa.us>, Regina Obe <r@pcorp.us>,
	pgsql-hackers@lists.postgresql.org
Subject: Re: [PATCH] Support % wildcard in extension upgrade filenames
Message-ID: <20230427104957.knkkt3klh5uabzke@c19>
References: <166914379479.1121.7549798686571352890.pgcf@coridan.postgresql.org>
 <55512.1673304709@sss.pgh.pa.us>
 <CA+RLCQwWpMuKtqg7eBOjvzpJc-hE708WpHG2=z5B969xncQS3w@mail.gmail.com>
 <20230409204629.sf4fptx672iehcau@c19>
 <000501d96c23$0f05bdf0$2d1139d0$@pcorp.us>
 <20230411184823.s3cctaf63qvfeqlj@c19>
 <006201d96cb5$3d23b150$b76b13f0$@pcorp.us>
 <20230411212737.phtzffycglbdhmpx@c19>
 <002201d96e57$e50461a0$af0d24e0$@pcorp.us>
 <CADsUR0AfzAcSEL4z4NzjQ2Kp16LXQx=dCc0oVvZuS_C_iNW1nQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CADsUR0AfzAcSEL4z4NzjQ2Kp16LXQx=dCc0oVvZuS_C_iNW1nQ@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/20230427104957.knkkt3klh5uabzke%40c19>
Precedence: bulk

On Mon, Apr 24, 2023 at 01:06:24PM -0400, Mat Arye wrote:
> Hi All,
> 
> I've done upgrade maintenance for multiple extensions now (TimescaleDB
> core, Promscale) and I think the original suggestion (wildcard filenames
> with control-file switch to enable) here is a good one.

Thanks for your comment, Mat.

I'm happy to bring back the control-file switch if there's an
agreement about that.

The rationale for me to add that was solely to be 100% sure about not
breaking any extension using "%" character as an actual version.

I never considered it a security measure because the author of the control
file is the same as the author of the ugprade scripts so shipping a
wildcard upgrade script could be seen as a switch itself.

[...]

> As for Tom's concern about downgrades, I think it's valid but it's a case
> that is easy to test for in Plpgsql and either handle or error. For
> example, we use semver so testing for a downgrade at the top of the upgrade
> script is trivial.

I'd say it could be made even easier if PostgreSQL itself would provide
a variable (or other way to fetch it) for the "source" version of the extension
during exection of the "source"--"target" upgrade.

I'm saying this because PostGIS fetches this version by calling a
PostGIS function, but some extensions might have such "version"
function pointing to a C file that doesn't exist enymore at the time
of upgrade and thus would be left with the impossibility to rely on
calling it.

--strk;