Re: Extension Facility

Поиск
Список
Период
Сортировка
От David E. Wheeler
Тема Re: Extension Facility
Дата
Msg-id 600C202C-FBBA-4DBD-A238-E02EFF95387D@kineticode.com
обсуждение исходный текст
Ответ на Re: Extension Facility  (Dimitri Fontaine <dfontaine@hi-media.com>)
Ответы Re: Extension Facility  (Dimitri Fontaine <dfontaine@hi-media.com>)
Список pgsql-hackers
On Jul 23, 2009, at 1:08 AM, Dimitri Fontaine wrote:

> Easy answer for first version: don't allow user to install extension  
> in
> another place than what we think will better suit him, and that's the
> new schema pg_extension, which always lies just before pg_catalog in  
> the
> search_path.

Well, I think that it's reasonable to allow an extension to be in any  
schema, with the default being pg_extension, but all of the objects in  
a single extension should assume that they're all in the same schema,  
at least to start. I mean, I can see the need for secondary schemas  
(or sub-schemas?) for encapsulation, but do we really need to go there  
in the first rev?

> Yes. I came up with the beginning of something (major version  
> dependant
> additional install.sql files) but then you need to control ordering,  
> so
> maybe pre and post install files with major version dependant
> derivatives. "Over engineered" is certainly the comment I'll hear  
> about
> it.

Yeah, so omit it for now, I say. Start with what's widely agreed-upon  
and relatively simple. We can iterate this pony over time.

Best,

David


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

Предыдущее
От: Jeremy Kerr
Дата:
Сообщение: [PATCH v4] [libpq] Try to avoid manually masking SIGPIPEs on every send()
Следующее
От: Dave Page
Дата:
Сообщение: Re: Upgrading our minimum required flex version for 8.5