Re: search_path vs extensions
От | David E. Wheeler |
---|---|
Тема | Re: search_path vs extensions |
Дата | |
Msg-id | 9E9925ED-B18A-4F85-9EFA-8ECBC3BFB5D3@kineticode.com обсуждение исходный текст |
Ответ на | Re: search_path vs extensions (Greg Stark <stark@enterprisedb.com>) |
Список | 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 по дате отправления: