Hi, "David E. Wheeler" <da...@kineticode.com> writes: > On May 25, 2009, at 2:16 AM, Dimitri Fontaine wrote: > >> Proposal: pg_extension, a new dedicated system schema for extensions > > I like this, although I'd want to be able, as a user, to override that > default and tell an extension to install in some other schema. That would > allow me to immediately overcome conflicts, and to organize my extensions > if I want, rather than throw them all in one place.
The moment you're adding specific schemas where to put extensions into, you have to adapt your search_path. Some applications already have to manage search_path for their own needs, so we're trying to avoid having those people to care about extensions schemas and application schema at the same time. It could even not be the same people caring about those search_path parts. >> Proposal: Separate search_path into components: pre_search_path, >> search_path, post_search_path > > I don't follow this at all. How to the three components effect behavior? And > what does this mean for where extensions are installed in schemas? This proposal tries to solve previous one limitations. It's very good in the typical case when you want each extension to be installed in one (or more) schemas but don't want to have the application to care about it. Then you add your extensions schemas into pre_search_path and application schemas into search_path, so that the application doesn't have to manage pre_search_path. Now it could be that your application is historically using the same function names as some extension you're now adding to the server, and you want to control which function is called when not schema qualified. So you have the post_search_path to play with too. The idea being that application developpers will maintain search_path for the application schemas (and this search_path can vary depending on the application role which connects to the database, of course), and the DBA team will make extensions available transparently to the application by adding the extension's schemas in either pre_search_path or post_search_path. I hope I've added clarity to the point, rather than only some extra verbosity... :) 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
