Re: Allow an extention to be updated without a script

From: Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>
To: Julien Rouhaud <rjuju123(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Allow an extention to be updated without a script
Date: 2023-02-01 08:32:52
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Wed, 1 Feb 2023 14:37:27 +0800
Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote:

> 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(at)sss(dot)pgh(dot)pa(dot)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
> > (
> > [...]
> 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.

Thank you for your comment and explanation. That helped me understand extension
release approaches.

I will withdraw the proposal since just providing empty update scripts can
resolve the problem and it wouldn't be worth the confusing.

Yugo Nagata

Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2023-02-01 08:38:36 Re: Exit walsender before confirming remote flush in logical replication
Previous Message Andres Freund 2023-02-01 07:55:46 Re: meson: pkgconfig difference