Re: search_path vs extensions
От | Tom Lane |
---|---|
Тема | Re: search_path vs extensions |
Дата | |
Msg-id | 14661.1243535909@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: search_path vs extensions (Greg Stark <stark@enterprisedb.com>) |
Ответы |
Re: search_path vs extensions
Re: search_path vs extensions |
Список | pgsql-hackers |
Greg Stark <stark@enterprisedb.com> writes: > 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. +1 ... naming conflicts between different extensions are going to be a problem for people no matter what. Sticking them in different schemas doesn't really fix anything, it just means that you'll hit the problems later instead of sooner. I suppose there might be some use-case involving concurrent installation of multiple versions of the *same* extension, but I'm not sure we should be designing around that as a key case. > 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. Well, an extension can certainly do that today, so why would it be a factor in this discussion? It's just an extra schema. And I guess the extension author has to explicitly qualify all those names, but if he doesn't want those names in the search path I don't see much choice. regards, tom lane
В списке pgsql-hackers по дате отправления: