Re: Extensions, patch v18 (merge against master, bitrot-only-fixes)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Extensions, patch v18 (merge against master, bitrot-only-fixes)
Дата
Msg-id 11852.1292532201@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Extensions, patch v18 (merge against master, bitrot-only-fixes)  (Alvaro Herrera <alvherre@commandprompt.com>)
Список pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Excerpts from Tom Lane's message of jue dic 16 17:10:10 -0300 2010:
>> However, the only way I can see to fix this "automatically" is to have
>> the makefiles propagate PG_VERSION_NUM (or one of the other values set
>> by configure) into generated control files.  I don't think that's what
>> we want either.  If we do that, then people are going to be forced to
>> go through an ALTER EXTENSION UPGRADE cycle whether or not anything
>> actually changed in the extension's SQL definitions.  We really only
>> want the extension's SQL version to change when there was a meaningful
>> change in the SQL commands.

> I've been wondering if we should stop thinking that each contrib's
> module version is the same as the backend version.

Right, they would have to be decoupled if you believe what I said above.

> In that case, having hand-maintained version numbers in control or
> wherever is not so much of a problem; the committer that touches the
> module needs to ensure that the version number is incremented too.

It would be tolerable, if perhaps error-prone.  But we've seldom blown
it on catversion, and this would be a comparable requirement.
        regards, tom lane


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [PATCH] V3: Idle in transaction cancellation
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [PATCH] V3: Idle in transaction cancellation