Re: Modifying and solidifying contrib

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: Modifying and solidifying contrib
Дата
Msg-id 45BE6ACC.6090204@dunslane.net
обсуждение исходный текст
Ответ на Re: Modifying and solidifying contrib  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: Modifying and solidifying contrib  (Bruce Momjian <bruce@momjian.us>)
Re: Modifying and solidifying contrib  (David Fetter <david@fetter.org>)
Список pgsql-hackers
Bruce Momjian wrote:
> Andrew Dunstan wrote:
>   
>> Bruce Momjian wrote:
>>     
>>> Keep in mind all contrib loads into public, and I don't remember any
>>> namespace conflict issues in the past.
>>>   
>>>       
>> That is beside the point. Of course there haven't been conflicts - 
>> precisely because a single group controls the whole lot. What I said was 
>> that we should behave as sane third party extension authors would, 
>> namely to use their own namespace to protect themselves from conflicts 
>> with other unknown extensions. It's called setting a good example or 
>> eating your own dog food.
>>     
>
> The problem I see controlling per-user search_path if +10 extensions are
> instlalled, and you want them always to be available by default.
>   

This suggests maybe we need to look at beefing up a few things. For 
example, an alias facility that provided a name in schema X for things 
in schema Y would help lots here. (You want everything visible? Just 
alias it in public.) ISTR such things in DB2, although it's now many 
years since I laid hands on it, so my memory could well be very faulty.

Also, ability to append to the search path rather than just set it could 
help, as might ability to add names of non-existent schemas (which would 
be ignored at run time when found not to exist).

cheers

andrew




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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Modifying and solidifying contrib
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Modifying and solidifying contrib