Skip site navigation (1) Skip section navigation (2)

Re: Extension Packaging

From: Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com>
To: Marko Kreen <markokr(at)gmail(dot)com>
Cc: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "David E(dot) Wheeler" <david(at)kineticode(dot)com>, "pgsql-hackers(at)postgresql(dot)org Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Extension Packaging
Date: 2011-04-28 13:40:04
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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

In response to


pgsql-hackers by date

Next:From: Marko KreenDate: 2011-04-28 13:53:57
Subject: Re: Extension Packaging
Previous:From: Pavan DeolaseeDate: 2011-04-28 13:36:10
Subject: Re: PostgreSQL Core Team

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group