| From: | "David E(dot) Wheeler" <david(at)kineticode(dot)com> |
|---|---|
| To: | "pgsql-hackers(at)postgresql(dot)org Hackers" <pgsql-hackers(at)postgresql(dot)org> |
| Cc: | 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-11 21:06:44 |
| Message-ID: | 83DF99A3-C282-4AC3-9B31-EADD03018EE3@kineticode.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Apr 28, 2011, at 2:16 PM, David E. Wheeler wrote:
> So maybe it's half-assed. Maybe the version can be anything but the revision must be an integer. Maybe there's a `pg_extension_version($extension_name)` function that returns ARRAY[$version, $revision], and the revision is set in the control file but not included in the version or in the upgrade file names. I think I can live with that. But, hell, you're halfway to mandating the meaning by doing this. Will we have to go the rest of the way in the future?
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?
Best,
David
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2011-05-11 21:10:12 | Re: Backpatching of "Teach the regular expression functions to do case-insensitive matching" |
| Previous Message | Tom Lane | 2011-05-11 21:06:02 | Re: VARIANT / ANYTYPE datatype |