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

Re: Extension Packaging

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com>
Cc: Marko Kreen <markokr(at)gmail(dot)com>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, "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 14:04:26
Message-ID: 26505.1303999466@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com> writes:
> On Thu, Apr 28, 2011 at 2:21 PM, Marko Kreen <markokr(at)gmail(dot)com> wrote:
>> 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.

I think what we're discussing here is bug-fix revisions that don't
affect the SQL declarations for the extension.  Presumably, that means a
change in the C code, so the shared library is the right place to keep
the revision number.  A version number in the control file seems to
carry a nontrivial risk of being out of sync with the actual code in the
shared library.

What's not clear to me is whether to just suggest that extension authors
who care about this should provide a foo_version() function, or to try
to standardize it a bit more than that.

One point worth thinking about is that not all extensions will have
a shared library at all --- SQL-only extensions have been mentioned
several times as an important use case.  For those, there's no such
thing as an update that doesn't change the script file, and we shouldn't
try to impose a requirement of providing a lower-level revision number.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2011-04-28 14:07:31
Subject: Re: unknown conversion %m
Previous:From: Boszormenyi ZoltanDate: 2011-04-28 14:03:56
Subject: TEXT vs PG_NODE_TREE in system columns (cross column and expression statistics patch)

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