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