Re: Allow an extention to be updated without a script

From: Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Allow an extention to be updated without a script
Date: 2023-01-31 02:17:22
Message-ID: 20230131111722.9e5779f326a70e58f5631fa1@sraoss.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Thank you for your comment.

On Mon, 30 Jan 2023 16:05:52 -0500
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Yugo NAGATA <nagata(at)sraoss(dot)co(dot)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(at)sraoss(dot)co(dot)jp>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2023-01-31 02:43:20 Re: Scan buffercache for a table
Previous Message Amin 2023-01-31 02:01:08 Scan buffercache for a table