Re: search_path vs extensions

Greg Stark <stark(at)enterprisedb(dot)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