Re: Extension Packaging

On Thu, Apr 28, 2011 at 2:21 PM, Marko Kreen <markokr(at)gmail(dot)com> wrote:
> On Thu, Apr 28, 2011 at 4:07 PM, Daniele Varrazzo
> <daniele(dot)varrazzo(at)gmail(dot)com> wrote:
>> On Wed, Apr 27, 2011 at 1:48 PM, Dimitri Fontaine
>> <dimitri(at)2ndquadrant(dot)fr> wrote:
>>> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.
>
> How about each .so containing a version callback?
>
> Thus you can show what is the version of underlying implementation
> without needing to mess with catalogs just to keep track of patchlevel
> of C code.

On this line, it would be easier to add a parameter "revision" to the
control file and have a function pg_revision(ext) to return it,
eventually showing in the \dx output. But this still assumes the
revision as being just a string, and if it has a semantic meaning then
it requires parsing to extract meaning for it (whereas foo_revision()
may return everything the author of foo thinks is important for code
depending on it to know, e.g. it may return an integer 90102 or a
record (major, minor, patch, status, svn-rev,
name-of-my-last-daughter). I don't think we want to force any
convention, such as the revision being a semver number - even if PGXN
restrict the extension to this strings subset.

-- Daniele