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</>.

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:

Reply via email to