On Mon, Jun 16, 2008 at 06:00:33PM -0400, Andrew Dunstan wrote: >> I, too, would be happy to do the legwork on this one. I believe >> we'd want to have both per-db and per-role settings for >> search_path. What's involved with creating that latter? > > Proper support for module install / uninstall will be a far better > solution. Why would you wast your time on something that will be at > best half-baked?
Maybe I'm missing something big, but I don't quite see what constitutes "proper" that doesn't involve the module's having at least one schema to itself. Does this mean we'd be freezing modules in their first-deployed form? It seems to me that DROP SCHEMA ... CASCADE is just the right level of modularity combined with flexibility post-installation. The way I've structured DBI-Link, for example, involves one schema for DBI-Link itself, modifiable by the DB superuser, and ancillary schemas for each link. Come to think of it, it would be nice if it were possible to tell pg_depend about such relationships between schemas, so that when somebody drops a schema with CASCADE, all schemas marked as depending on it also disappear... As to why you'd want per-role, per-DB search_paths, right now, you can set them only per-role, which results in an annoying number of "path not found" warnings should a user switch to a DB in the cluster which doesn't contain all the schemas in its default search_path. Another way would be for people to be able to set <flame-proof_suit>some kind(s) of configurable action(s) on CONNECT</>. Cheers, David. -- David Fetter <[EMAIL PROTECTED]> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers