Re: Extension Packaging

Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com> writes:
> On Thu, Apr 21, 2011 at 4:16 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> If you did not actually change the contents of the install script, you
>> should not change its version number either.

> Sorry, I'm not entirely convinced. If I release an extension 1.0, then
> find a bug in the C code and fix it in 1.0.1, arguably "make install"
> will put the .so in the right place and the 1.0.1 code will be picked
> up by new sessions. But pg_extension still knows 1.0 as extension
> version, and ALTER EXTENSION ... UPGRADE fails because no update path
> is knows.

If you didn't change the install script then it's not necessary to
execute ALTER EXTENSION ... UPGRADE. You seem to be assuming that the
pg_extensions catalog has to reflect the bug fix level of an extension,
but that is *not* the intention. If it did reflect that, you'd need
N times as many upgrade scripts, most of them identical, to deal with
updating from different bug fix levels of the prior version.

IMO it'd be better if the bug fix level was tracked outside the
database, for instance via an RPM package version/release number.
I'm not sure whether PGXN has anything for that at the moment.

For a comparative data point, there is no catalog-related way to tell
which minor release number you are running within a Postgres major
release. There is the version() function, so one way to deal with this
would be to provide a version()-like function for your extension.

> There is also a dangerous asymmetry: If I'm not mistaken the library
> .so has no version number, so there can be only one version in the
> system: an update changing code and sql requires ALTER EXTENSION to be
> run as soon as possible, or some sql function from the old extension
> may try to call non-existing functions in the library - or worse the
> wrong ones or with wrong parameters.

We've been over that in the previous discussions, please see the
archives. I believe the conclusion was that breaking ABI compatibility
within an update is just not a good idea.

regards, tom lane