Re: ALTER EXTENSION ... UPGRADE;

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>, "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 22:43:31
Message-ID: 2064.1292021011@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Josh Berkus <josh(at)agliodbs(dot)com> writes:
> 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.
> ...
> 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.

99% of the time, "fix a bug" just means some C code changes. We should
not force DBAs to go through special upgrade commands unless there is
some change in the SQL objects created by the extension --- and just as
we discourage changes in the SQL objects created by the core during
minor releases, we should discourage such changes in minor extension
updates. So the case where ALTER EXTENSION UPGRADE is needed will be
the exception not the rule.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dimitri Fontaine 2010-12-10 22:43:32 Re: ALTER EXTENSION ... UPGRADE;
Previous Message Tom Lane 2010-12-10 22:40:07 Re: ALTER EXTENSION ... UPGRADE;