Greg Stark <st...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers