Date: Wed, 11 Jan 2023 11:16:36 +0100
From: 'Sandro Santilli' <strk@kbt.io>
Sender: strk@kbt.io
To: Regina Obe <lr@pcorp.us>
Cc: '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: <20230111101636.ybho2vesvatwmqyl@c19>
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>
 <000201d92572$7dcd8260$79688720$@pcorp.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <000201d92572$7dcd8260$79688720$@pcorp.us>
Archived-At: <https://www.postgresql.org/message-id/20230111101636.ybho2vesvatwmqyl%40c19>
Precedence: bulk

On Tue, Jan 10, 2023 at 11:09:23PM -0500, Regina Obe wrote:

> The only way we can fix that in the current setup, is to move to a minor
> version mode which means we can 
> never do micro updates.

Or just not with standard PostgreSQL syntax, because we can of course
do upgrades using the `SELECT postgis_extensions_upgrade()` call at
the moment, which, if you ask me, sounds MORE dangerous than the
wildcard upgrade approach because the _implementation_ of that
function will always be the OLD implementation, never the NEW one,
so if bogus cannot be fixed by a new release w/out a way to upgrade
there...

--strk;