Re: search_path vs extensions

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> The contents of a particular schema are more or less analagous to an
> application. In most programming languages, an application informs
> the system of the libraries that it needs and the system goes off and
> loads the symbols in those libraries into the application's namespace.
> Using search path basically requires the user to tell the application
> where to find those symbols, which ISTM is exactly backwards.

Well, in fact, not so much, because the application is using SET to tell
the system where to search for needed objects. That's about the same as
your loading lib into the application namespace analogy.

Now, using PostgreSQL, you can pre-set the setting at the database and
role levels in order not to have to manage it explicitly in the
application code. That's only a DBA convenience though, for places where
the code and the database are not managed by the same teams (or at least
it's the way I think about it --- this and database upgrades without
costly application rewrites).

> Also, it seems to me that we could create a system schema called
> something like pg_extension and make it empty. Every extension could
> install in its own schema and then tell pg_extension to inherit it
> that schema. Then if you want to just get all the extensions, you can
> just set your search path to include pg_extension, and as new
> extensions are added or old ones are removed, you'll still have all
> the extensions without changing anything.

Then you do the exact same thing with the public schema in the first
place, inheriting pg_extension if needed, and you deprecate search_path
entirely. Don't forget the schemas are not there to solve extension
managing problems, but a separate tool that have a great overlay with
extensions, because we tend to like to have a schema (or more) per
extension.

Your proposal doesn't include any notion of search order within the tree
of available schemas, which means we're loosing half of the search_path
features (the other half is restricting the searches, which you address).

I think I'm failing to understand where your proposal leads us the same
way you seem to be failing to follow mine...

Regards,
--
dim