Thread: Allow an extention to be updated without a script

Allow an extention to be updated without a script

From
Yugo NAGATA
Date:
Hi hackers,

I propose to add a new option "updates_without_script" to extension's
control file which a list of updates that do not need update script. 
This enables to update an extension by ALTER EXTENSION even if the
extension module doesn't provide the update script.

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.

The attached patch introduces a new option "updates_without_script"
into extension control file. This specifies a list of such updates
following the pattern 'old_version--target_version'. 

For example, 

 updates_without_script = '1.1--1.2, 1.3--1.4'
 
means that updates from version 1.1 to version 1.2 and from version 1.3
to version 1.4 don't need an update script.  In this case, users don't
need to prepare update scripts extension--1.1--1.2.sql and
extension--1.3--1.4.sql if it is not necessary to execute any commands.

The updated path of an extension is determined based on both the filenames
of update scripts and the list of updates specified in updates_without_script.
Presence of update script has higher priority than the option. Therefore,
if an update script is provided, the script will be executed even if this
update is specified in updates_without_script.

What do you think of this feature?
Any feedback would be appreciated.

Regards,
Yugo Nagata

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

Attachment

Re: Allow an extention to be updated without a script

From
Tom Lane
Date:
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.

> The attached patch introduces a new option "updates_without_script"
> into extension control file. This specifies a list of such updates
> following the pattern 'old_version--target_version'.

This seems completely unnecessary and confusing.

            regards, tom lane



Re: Allow an extention to be updated without a script

From
Yugo NAGATA
Date:
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>



Re: Allow an extention to be updated without a script

From
Julien Rouhaud
Date:
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.



Re: Allow an extention to be updated without a script

From
Yugo NAGATA
Date:
On Wed, 1 Feb 2023 14:37:27 +0800
Julien Rouhaud <rjuju123@gmail.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@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.

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. 

Regards,
Yugo Nagata

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