From: | Greg Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "David E(dot) Wheeler" <david(at)kineticode(dot)com> |
Cc: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: search_path vs extensions |
Date: | 2009-05-28 18:27:01 |
Message-ID: | 4136ffa0905281127u4f29a13egba4c8b62aa07cfd2@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, May 28, 2009 at 5:30 PM, David E. Wheeler <david(at)kineticode(dot)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.
Actually there is another reason separate schemas does make some sense
to me. Private objects that the extension will use internally but
doesn't intend to make part of its public interface. It might be nice
if extensions could mark objects with a token like _private and have
that be created in a private schema separate from other extensions and
not in the default search path.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2009-05-28 18:37:01 | Re: search_path vs extensions |
Previous Message | Tom Lane | 2009-05-28 18:12:39 | Re: proposal: early casting in plpgsql |