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 <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
