Re: search_path vs extensions - Mailing list pgsql-hackers

From David E. Wheeler
Subject Re: search_path vs extensions
Date
Msg-id 9E9925ED-B18A-4F85-9EFA-8ECBC3BFB5D3@kineticode.com
Whole thread Raw
In response to Re: search_path vs extensions  (Greg Stark <stark@enterprisedb.com>)
List pgsql-hackers
On May 28, 2009, at 11:27 AM, Greg Stark wrote:

> On Thu, May 28, 2009 at 5:30 PM, David E. Wheeler <david@kineticode.com 
> > wrote:
>> Yes, just as long as your extensions schema doesn't turn into a  
>> bricolage of
>> stuff. I mean, if I use a lot of extensions, it means that I end up  
>> with a
>> giant collection of functions and types and whatnot in this one  
>> namespace.
>> PHP programmers might be happy with it, but not I. ;-P
>
> I don't understand what storing them in different namespaces and then
> putting them all in your search_path accomplishes. You end up with the
> same mishmash of things in your namespace.
>
> The only way that mode of operation makes any sense to me is if you
> explicitly prefix every invocation. Ie, you want the stuff installed
> but not available in your namespace at all unless you explicitly
> request it.

Yes, it allows me to work around a conflict in my application by  
deciding to schema-qualify use of a one of the two conflicting  
extensions. It's a way I can quickly work around the issue. Not ideal,  
I grant you, but I don't see us getting into the business of setting  
up a registry requiring uniqueness. Besides, some extensions, like  
pgTAP, pretty much scream for a schema of their own completely  
independent of everything else. I want the option to be able to do  
that when appropriate. I don't think I'd ever put each module in its  
own schema, FWIW.

Best,

David


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: libpq is not thread safe
Next
From: "David E. Wheeler"
Date:
Subject: Re: search_path vs extensions