Re: Extension Packaging - Mailing list pgsql-hackers
| From | Peter van Hardenberg |
|---|---|
| Subject | Re: Extension Packaging |
| Date | |
| Msg-id | BANLkTik3uCRG8kuaEvp39kxdQQs8tSnMqA@mail.gmail.com Whole thread Raw |
| In response to | Re: Extension Packaging ("David E. Wheeler" <david@kineticode.com>) |
| Responses |
Re: Extension Packaging
("David E. Wheeler" <david@kineticode.com>)
|
| List | pgsql-hackers |
My apologies for wading in out of the blue here as a first time poster with big demands, but allow me to briefly state my hopes without trying to be too proscriptive about particular mechanisms.
--
Peter van Hardenberg
San Francisco, California
"Everything was beautiful, and nothing hurt." -- Kurt Vonnegut
My hope here is that the extension model should eventually enable me to offer the ability for non-superuser databases to specify by some mechanism the extensions that they require in a reproducible fashion, enabling my users to recreate their local development conditions on a production cluster.
My particular worry, and I apologize if I have misunderstood the thrust of this thread, is that "extension version" might not be tied to the "extension revision", and so I will not be able to determine whether or not all existing extensions are already at a specific version.
The precision of this process is very important to me. My intended use case for this feature is to allow users to specify the versions of extensions that they need in some kind of a control file or in a database migration script such that they can then install those extensions on various new systems in a reliable and reproducible way.
David, if you do what you propose, haven't I already lost?
---
Peter van Hardenberg
Heroku
On Wed, May 11, 2011 at 7:48 PM, David E. Wheeler <david@kineticode.com> wrote:
On May 11, 2011, at 2:47 PM, Robert Haas wrote: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.
>> 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.
Best,
David--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
Peter van Hardenberg
San Francisco, California
"Everything was beautiful, and nothing hurt." -- Kurt Vonnegut
pgsql-hackers by date: