Re: Modifying and solidifying contrib - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Modifying and solidifying contrib
Date
Msg-id 45BE6ACC.6090204@dunslane.net
Whole thread Raw
In response to Re: Modifying and solidifying contrib  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Modifying and solidifying contrib  (Bruce Momjian <bruce@momjian.us>)
Re: Modifying and solidifying contrib  (David Fetter <david@fetter.org>)
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Modifying and solidifying contrib
Next
From: Bruce Momjian
Date:
Subject: Re: Modifying and solidifying contrib