From: | "David E(dot) Wheeler" <david(at)kineticode(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org Hackers" <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com>, Marko Kreen <markokr(at)gmail(dot)com>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr> |
Subject: | Re: Extension Packaging |
Date: | 2011-05-12 02:48:35 |
Message-ID: | C03E37CC-1043-4A32-A15F-32E5CC7238F5@kineticode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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't have 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 change much in the code. And I'll just keep using the full version string (x.y.z) for the upgrade scripts. What I won't do is change that version with every release, unless there is a code change to demand it. The distribution version can increment independently.
Best,
David
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-05-12 03:53:55 | Re: Extension Packaging |
Previous Message | Fujii Masao | 2011-05-12 02:41:12 | Re: Standbys which don't synch to disk? |