Re: search_path vs extensions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: search_path vs extensions
Date
Msg-id 14661.1243535909@sss.pgh.pa.us
Whole thread Raw
In response to Re: search_path vs extensions  (Greg Stark <stark@enterprisedb.com>)
Responses Re: search_path vs extensions  ("David E. Wheeler" <david@kineticode.com>)
Re: search_path vs extensions  (Peter Eisentraut <peter_e@gmx.net>)
List 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 by date:

Previous
From: Josh Berkus
Date:
Subject: Re: search_path vs extensions
Next
From: Tom Lane
Date:
Subject: Re: search_path vs extensions