Re: Extension Packaging - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Extension Packaging
Date
Msg-id BANLkTinFX4c358jBn3eYsT+r1bjmaEywgA@mail.gmail.com
Whole thread Raw
In response to Re: Extension Packaging  ("David E. Wheeler" <david@kineticode.com>)
List pgsql-hackers
On Wed, May 11, 2011 at 10:48 PM, David E. Wheeler <david@kineticode.com> wrote:
> On May 11, 2011, at 2:47 PM, Robert Haas wrote:
>
>>> Okay, how we add a "revision" key to the control file and extrevision to the pg_extension catalog. Its type can be
"TEXT"and is optional for use by extensions. 
>>>
>>> This would allow extension authors to identify the base version of an extension but also the revision. And the core
doesn'thave to care how it works or if it's used, but it would allow users to know exactly what they have installed. 
>>>
>>> Thoughts?
>>
>> How would pg_extension.extrevision be kept up to date?  AFAICS, the
>> whole point is that you might swap out the shared libraries without
>> doing anything at the SQL level.
>
> Bah! Okay, I give up. I'll not worry about it right now, as I have only one C extension outside of core and it won't
changemuch in the code. And I'll just keep using the full version string (x.y.z) for the upgrade scripts. What I won't
dois change that version with every release, unless there is a code change to demand it. The distribution version can
incrementindependently. 

What might work is to have the view call some function
pg_get_the_revision_from_the_control_file_or_some_other_place_in_the_filesystem('extension-name').

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: "David E. Wheeler"
Date:
Subject: Re: Extension Packaging
Next
From: Peter Eisentraut
Date:
Subject: Re: pg_upgrade and PGPORT