Re: Extension Packaging

Поиск
Список
Период
Сортировка
От Marko Kreen
Тема Re: Extension Packaging
Дата
Msg-id BANLkTi=-qmdTji08A+pXJE8SVJeGBMeWTQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Extension Packaging  (Daniele Varrazzo <daniele.varrazzo@gmail.com>)
Ответы Re: Extension Packaging  (Daniele Varrazzo <daniele.varrazzo@gmail.com>)
Список pgsql-hackers
On Thu, Apr 28, 2011 at 4:07 PM, Daniele Varrazzo
<daniele.varrazzo@gmail.com> wrote:
> On Wed, Apr 27, 2011 at 1:48 PM, Dimitri Fontaine
> <dimitri@2ndquadrant.fr> wrote:
>> Tom Lane <tgl@sss.pgh.pa.us> writes:
>>> If you didn't change the install script then it's not necessary to
>>> execute ALTER EXTENSION ... UPGRADE.  You seem to be assuming that the
>>> pg_extensions catalog has to reflect the bug fix level of an extension,
>>> but that is *not* the intention.  If it did reflect that, you'd need
>>> N times as many upgrade scripts, most of them identical, to deal with
>>> updating from different bug fix levels of the prior version.
>>
>> +1 — but this discussion shows we're not exactly finished here.
>
> Probably what is needed is only a clarification that the version
> number is only about schema object, not revision, patch level, release
> status or whatever else semantically meaningful. I've attached a patch
> for the docs about the point.

How about each .so containing a version callback?

Thus you can show what is the version of underlying implementation
without needing to mess with catalogs just to keep track of patchlevel
of C code.

--
marko


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

Предыдущее
От: Daniele Varrazzo
Дата:
Сообщение: Re: Extension Packaging
Следующее
От: Tom Lane
Дата:
Сообщение: Re: VX_CONCURRENT flag on vxfs( 5.1 or later) for performance for postgresql?