Re: search_path vs extensions
От | Greg Stark |
---|---|
Тема | Re: search_path vs extensions |
Дата | |
Msg-id | 4136ffa0905291241s7c1aa92ax7d7c8b8238a7e710@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: search_path vs extensions ("David E. Wheeler" <david@kineticode.com>) |
Ответы |
Re: search_path vs extensions
(Tom Lane <tgl@sss.pgh.pa.us>)
Re: search_path improvements WAS: search_path vs extensions (Josh Berkus <josh@agliodbs.com>) Re: search_path vs extensions ("David E. Wheeler" <david@kineticode.com>) Re: search_path vs extensions (Greg Smith <gsmith@gregsmith.com>) |
Список | pgsql-hackers |
On Fri, May 29, 2009 at 5:23 PM, David E. Wheeler <david@kineticode.com> wrote: >> PS: we still have to provide users with easy tools to (dynamically) manage >> search_path, don't we? >> (I prefer not to start the search_path management tool ideas right here). > > Yes, we do, and that's what at least half this thread is about. Whether or > not such tools are put to use for extensions support is a separate issue, > but both need addressing, I think. Do we really? The only reason people are having trouble managing their search_path is because they're not using it as intended and putting things in lots of different schemas that they intend to all be visible. If they put everything they intend to be visible to users in one schema they wouldn't have this problem. That said, I don't mind the idea of having a way to push things onto search path like you often do in sh using PATH=/foo/bar:$PATH. But I think the only reason to install something into a separate schema is precisely if you *want* that schema to not be visible to users automatically. So having more and more complex ways to include schemas in the search path automatically is fixing a problem created by setting things up wrong in the first place. I'm actually not sure if we should allow extensions to be installed into separate schemas. If you do then it means we can't detect conflicts. A module might refer to an object intending to get its local object but end up getting some object from some other module depending on how the user set up his search_path. To make installing into separate schemas work we would have to have each extension have some magic way to refer to its own schema and enforce that all objects are referred to this way. We don't have any way to do that currently and I think that would also limit our ability to have extensions which depend on other extensions. In short I think people who want to put things in different schemas are being misled by their intuition. By installing everything into one schema you end up with a *more* organized system where everything has a well defined meaning. If you install everything in different schemas then that's where you end up with a mishmash where you're not sure what objects are being used when depending on a global run-time parameter which might need to be set differently for each module. -- greg
В списке pgsql-hackers по дате отправления: