Re: Allow an extention to be updated without a script - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: Allow an extention to be updated without a script
Date
Msg-id 20230201063727.ur4j7sx7xrrbl5zt@jrouhaud
Whole thread Raw
In response to Re: Allow an extention to be updated without a script  (Yugo NAGATA <nagata@sraoss.co.jp>)
Responses Re: Allow an extention to be updated without a script
List pgsql-hackers
Hi,

On Tue, Jan 31, 2023 at 11:17:22AM +0900, Yugo NAGATA wrote:
>
> On Mon, 30 Jan 2023 16:05:52 -0500
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> > If you have no update script, why call it a new version?  The point
> > of extension versions is to distinguish different states of the
> > extension's SQL objects.  We do not consider mods in underlying C code
> > to justify a new version.
>
> Although, as you say, the extension manager doesn't track changes in C code
> functions, a new version could be released with changes in only in C
> functions that implement a new feature or fix some bugs because it looks
> a new version from user's view.  Actually, there are several extensions
> that provide empty update scripts in order to allow user to install such
> new versions, for example;
>
> [...]
> - hypopg
>  (https://github.com/HypoPG/hypopg/blob/REL1_STABLE/hypopg--1.3.1--1.3.2.sql)
> [...]

Indeed, almost all users don't really understand the difference between the
module / C code and the extension, and that gets worse when
shared_preload_libraries gets in the way.

I personally choose to ship "empty" extension versions so that people can
upgrade it if they want to have e.g. the OS level version match the SQL level
version.  I know some extensions that chose a different approach: keep the
first 2 digits for anything that involves extension changes and have a 3rd
digit for C level bugfix only.  But they get very frequent bug reports about
version mismatch any time a C bugfix is released, so I will again personally
keep shipping those useless versions.  That being said, I agree with Tom here
and we shouldn't add hacks for that.



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [Commitfest 2023-01] has started
Next
From: Thomas Munro
Date:
Subject: Re: odd buildfarm failure - "pg_ctl: control file appears to be corrupt"