On Sun, Apr 24, 2011 at 10:46 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Daniele Varrazzo <daniele.varrazzo@gmail.com> writes:
>> On Thu, Apr 21, 2011 at 4:16 AM, Tom Lane <tgl@sss.pgh.pa.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.
Yes, I was assuming that the pg_extension catalog should have included
the bug fix level, and I noticed the explosion of upgrade paths
required.
> 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.
PGXN requires a version for the extension, possibly including the
patchlevel (well, actually forcing a patchlevel, as per semver spec),
and I/David/probably everybody else were thinking that such version
ought to be the same specified in the .control file. I see that a
better guideline would be to have '1.0' specified in the control and
'1.0.X' in the metadata submitted on PGXN, which I think is not
currently the case - see for example
http://api.pgxn.org/src/pair/pair-0.1.2/pair.control
-- Daniele