Thread: Allow an extention to be updated without a script
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
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
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>
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.
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>