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

From Yugo NAGATA
Subject Re: Allow an extention to be updated without a script
Date
Msg-id 20230131111722.9e5779f326a70e58f5631fa1@sraoss.co.jp
Whole thread Raw
In response to Re: Allow an extention to be updated without a script  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Allow an extention to be updated without a script
List pgsql-hackers
Hi,

Thank you for your comment.

On Mon, 30 Jan 2023 16:05:52 -0500
Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Yugo NAGATA <nagata@sraoss.co.jp> writes:
> > Currently, even when we don't need to execute any command to update an
> > extension from one version to the next, we need to provide an update
> > script that doesn't contain any command. Preparing such meaningless
> > files are sometimes annoying.
> 
> 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;

- pglogical
 (https://github.com/2ndQuadrant/pglogical/blob/REL2_x_STABLE/pglogical--2.4.1--2.4.2.sql)
- hll
 (https://github.com/citusdata/postgresql-hll/blob/master/update/hll--2.16--2.17.sql)
- orafce
 (https://github.com/orafce/orafce/blob/master/orafce--3.12--3.13.sql)
- hypopg
 (https://github.com/HypoPG/hypopg/blob/REL1_STABLE/hypopg--1.3.1--1.3.2.sql)
- timescaledb
 (https://github.com/timescale/timescaledb/blob/main/sql/updates/2.9.2--2.9.1.sql)


-- 
Yugo NAGATA <nagata@sraoss.co.jp>



pgsql-hackers by date:

Previous
From: Amin
Date:
Subject: Scan buffercache for a table
Next
From: Justin Pryzby
Date:
Subject: Re: Scan buffercache for a table