Re: search_path vs extensions
От | David E. Wheeler |
---|---|
Тема | Re: search_path vs extensions |
Дата | |
Msg-id | 25EB162D-029C-45A7-A68D-576B96ED5B41@kineticode.com обсуждение исходный текст |
Ответ на | Re: search_path vs extensions (Dimitri Fontaine <dfontaine@hi-media.com>) |
Ответы |
Re: search_path vs extensions
|
Список | pgsql-hackers |
On May 28, 2009, at 1:13 AM, Dimitri Fontaine wrote: > Having all extensions live in pg_extension schema also solves the > problem in a much easier way, except for people who care about not > messing it all within a single schema (fourre-tout is the french for a > place where you put anything and everything). 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 > As Josh is saying too, as soon as we have SQL level extension object > with dependancies, we'll be able to list all of a particular > extension's > objects without needing to have them live in separate schemas. > \df pgq. -- list all functions in schema pgq > \dt pgq. -- list all tables in schema pgq > \de pgq. -- list all objects provided by extension pgq > > Still, for extension upgrading or name collisions between > extensions, or > some more cases I'm not thinking about now, pg_extension will not be > all > what you need. We already have schemas and search_path, and it's not > always pretty nor fun to play with. Would prefix/suffix components > help? Yes, but I'm not sure that's the best interface for that functionality. Think I'll do some thinking on it myself… Best, David
В списке pgsql-hackers по дате отправления: