Re: search_path vs extensions

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: search_path vs extensions
Дата
Msg-id 4A1FED0A.40500@dunslane.net
обсуждение исходный текст
Ответ на Re: search_path vs extensions  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: search_path vs extensions  (Dimitri Fontaine <dfontaine@hi-media.com>)
Список pgsql-hackers

Peter Eisentraut wrote:
> On Thursday 28 May 2009 02:57:00 Josh Berkus wrote:
>   
>> Personally, if we're tracking stuff through special dependancies which
>> pg_dump will be aware of anyway, I don't see why extension objects
>> should go into a special schema.
>>     
>
> But they clearly have to go into *some* schema, and it would add some clarity 
> to the world if we made a recommendation which one that is.  Which is what 
> some of the subproposals really come down to.
>   

Even that's going to be hard, frankly. The usage pattern is likely to be 
too varied for any one-size-fits-all recommendation.

Proposals to allow a choice of schema at install time sound nice but in 
practice they are a recipe for massive headaches and maintenance 
nightmares, I think. It means no extension author will be able to 
hardcode the schema name in any view, function etc. Yuck.

I think almost all these difficulties could be overcome if we had some 
sort of aliasing support, so that arbitrary objects in schema a could be 
aliased in schema b.  If that were in place, best practice would 
undoubtedly be for each module to install in its own schema, and for the 
DBA to alias what is appropriate to their usage scenario. But unless 
someone wants to tackle that  I think we should leave schema management 
entirely alone, and leave it up to the extension author / DBA between them.

cheers

andrew


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

Предыдущее
От: Michael Meskes
Дата:
Сообщение: Re: Warnings in compile
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pg_migrator and an 8.3-compatible tsvector data type