On Wed, May 11, 2011 at 5:06 PM, David E. Wheeler <da...@kineticode.com> wrote: > 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?
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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
