On Wed, Apr 27, 2011 at 1:48 PM, Dimitri Fontaine
<dimi...@2ndquadrant.fr> wrote:
> Tom Lane <t...@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
From 03fa593a46f1dae0a8e83b4bccd6dea51e2c102c Mon Sep 17 00:00:00 2001
From: Daniele Varrazzo <daniele.varra...@gmail.com>
Date: Thu, 28 Apr 2011 14:02:08 +0100
Subject: [PATCH] Added paragraph about the distinction between extension version and patch level.
---
doc/src/sgml/extend.sgml | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/doc/src/sgml/extend.sgml b/doc/src/sgml/extend.sgml
index 4ca17ef..ad26f5a 100644
--- a/doc/src/sgml/extend.sgml
+++ b/doc/src/sgml/extend.sgml
@@ -767,6 +767,20 @@ SELECT pg_catalog.pg_extension_config_dump('my_config', 'WHERE NOT standard_entr
</para>
<para>
+ Note that version names are only meant to give an identity to the set of
+ objects in the database schema and should not be used to track outside
+ objects such as shared libraries or data files. Specifically, if the
+ extension has a concept of <firstterm>revision</> or <firstterm>patch
+ level</> (maybe loaded with semantic meaning such as revisions order or
+ release status), setting a version equal to the patch level is
+ discouraged as it would require a large number of mostly equal (or empty)
+ upgrade scripts. For example, if a bug is found in the C code of the
+ extension <literal>foo</> version <literal>1.0</> you may want to release
+ a revision <literal>1.0.1</> but you should leave the version as
+ <literal>1.0</> if no object in the database schema is changed.
+ </para>
+
+ <para>
Sometimes it is useful to provide <quote>downgrade</> scripts, for
example <literal>foo--1.1--1.0.sql</> to allow reverting the changes
associated with version <literal>1.1</>. If you do that, be careful
--
1.7.1
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
