| From: | Josh Berkus <josh(at)agliodbs(dot)com> |
|---|---|
| To: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "David E(dot) Wheeler" <david(at)kineticode(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: ALTER EXTENSION ... UPGRADE; |
| Date: | 2010-12-10 21:55:08 |
| Message-ID: | 4D02A1BC.9090406@agliodbs.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 12/10/10 12:34 PM, Dimitri Fontaine wrote:
> Josh Berkus <josh(at)agliodbs(dot)com> writes:
>> I think that each contrib needs its own version numbers. The reason
>> being that most minor updates don't touch contrib.
>
> Fair enough. What are the version numbers of each current contribs?
I'd say that for anything in /contrib, it gets a new version with each
major version of postgresql, but not with each minor version. Thus,
say, dblink when 9.1.0 is release would be dblink 9.1-1. If in 9.1.4 we
fix a bug in dblink, then it becomes dblink 9.1-2.
This is confusing from a version number perpsective, but it prevents
admins from having to run extension upgrades when nothing has changed.
The alternative would be to match postgresql minor version numbering
exactly, and then come up with some way to have a "no-op" upgrade in the
frequent cases where the contrib module isn't changed during a minor
release. This would also require some kind of "upgrade all" command for
contrib.
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dimitri Fontaine | 2010-12-10 22:00:18 | Re: ALTER EXTENSION ... UPGRADE; |
| Previous Message | Dimitri Fontaine | 2010-12-10 21:50:59 | Re: ALTER EXTENSION ... UPGRADE; |