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.
> 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.
> 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.
IOW, ABI should be tied to version, not to revision, I think.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
