On Wed, Apr 27, 2011 at 1:48 PM, Dimitri Fontaine
<dimitri@2ndquadrant.fr> wrote:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> 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.
>
> +1 — but this discussion shows we're not exactly finished here.
Probably what is needed is only a clarification that the version
number is only about schema object, not revision, patch level, release
status or whatever else semantically meaningful. I've attached a patch
for the docs about the point.
>> 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.
>
> -0.5
>
> What I think would be useful here is to have both version and revision
> in the control file and pg_extension catalog. Then an extension can
> easily be at version 1.2 and revision 1.2.3.
>
> Now, that means that ALTER EXTENSION UPGRADE should accept to upgrade
> the revision in the control file when nothing else changes.
A less invasive change would be to just update the extension comment
on ALTER EXTENSION UPGRADE. This means that the revision would be just
informative and not metadata available to eventual depending code but
it's on purpose. I think that, if an extension requires its patchlevel
to be known, e.g. because depending code has to take different actions
based on the revision, it should really provide an inspection
function, such as foo_revision(), so that pre-9.1 code can work with
it as well.
-- Daniele