Re: search_path vs extensions

On Fri, May 29, 2009 at 5:23 PM, David E. Wheeler <david(at)kineticode(dot)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