On Wed, 1 Feb 2023 14:37:27 +0800 Julien Rouhaud <rjuju...@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 <t...@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 <nag...@sraoss.co.jp>
