Re: ALTER EXTENSION ... UPGRADE;

Поиск
Список
Период
Сортировка
От Josh Berkus
Тема Re: ALTER EXTENSION ... UPGRADE;
Дата
Msg-id 4D02A1BC.9090406@agliodbs.com
обсуждение исходный текст
Ответ на Re: ALTER EXTENSION ... UPGRADE;  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Ответы Re: ALTER EXTENSION ... UPGRADE;  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Re: ALTER EXTENSION ... UPGRADE;  ("David E. Wheeler" <david@kineticode.com>)
Re: ALTER EXTENSION ... UPGRADE;  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 12/10/10 12:34 PM, Dimitri Fontaine wrote:
> Josh Berkus <josh@agliodbs.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
 


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Dimitri Fontaine
Дата:
Сообщение: Re: ALTER EXTENSION ... UPGRADE;
Следующее
От: Dimitri Fontaine
Дата:
Сообщение: Re: ALTER EXTENSION ... UPGRADE;