Re: Extension Packaging

Поиск
Список
Период
Сортировка
От David E. Wheeler
Тема Re: Extension Packaging
Дата
Msg-id CA8D96A7-7D1C-4091-A092-77BC977523BF@kineticode.com
обсуждение исходный текст
Ответ на Re: Extension Packaging  (Aidan Van Dyk <aidan@highrise.ca>)
Ответы Re: Extension Packaging  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Apr 25, 2011, at 9:14 AM, Aidan Van Dyk wrote:

> Really, that means you just a sql function to your extension,
> somethign similary to uname -a, or rpm -qi, which includes something
> that is *forced* to change the postgresql catalog view of your
> extension every time you ship a new version (major, or patch), and
> then you get the exact version (and whatever else you include) for
> free every time you update ;-)

I think it's silly for every extension to have its own function that does this. Every one would have a different name
and,perhaps, signature. 

> The thing to remember is that the postgresql "extensions" are managing
> the *postgresql catalogs* view of things, even though the shared
> object used by postgresql to provide the particular catalog's
> requirements can be "fixed".
>
> If your extension is almost exclusively a shared object, and the only
> catalog things are a couple of functions defined to point into the C
> code, there really isn't anything catalog-wise that you need to
> "manage" for upgrades.

Most of my extensions will not be written in C (e.g., pgTAP, explanation).

Best,

David




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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: offline consistency check and info on attributes
Следующее
От: Tom Lane
Дата:
Сообщение: Unfriendly handling of pg_hba SSL options with SSL off