Re: Extensions User Design

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Extensions User Design
Дата
Msg-id 200906291548.19839.peter_e@gmx.net
обсуждение исходный текст
Ответ на Re: Extensions User Design  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: Extensions User Design  (Richard Huxton <dev@archonet.com>)
Список pgsql-hackers
On Thursday 25 June 2009 01:09:17 Andrew Dunstan wrote:
> Well, I think in our case that would be going too far. I think there is
> a very good case for keeping a few key extensions in core both as
> exemplars and to make it easy to validate the extension mechanism
> itself. There have been suggestions in the past about throwing a bunch
> of things overboard, sometimes out of a passion for neatness more than
> anything else ISTM, but there have been good arguments against as well,
> particularly in the case of the PLs, which are tied so closely to the
> backend.

Another thing we might want to consider once we have a robust extension 
mechanism is to move some things out of the backend into extensions.  
Candidates could be uuid, legacy geometry types, inet/cidr, for example.  
These extensions would still be available and probably installed by default, 
but they need not be hardcoded into the backend.  But a policy of shipping 
zero extensions with the postgresql tarball obviously leaves very little 
flexibility to do any sort of thing like this.


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

Предыдущее
От: Tsutomu Yamada
Дата:
Сообщение: Re: Proposal: More portable way to support 64bit platforms
Следующее
От: Richard Huxton
Дата:
Сообщение: Re: Extensions User Design