Robert Treat wrote:
On Monday 16 June 2008 21:12:23 Andrew Dunstan wrote:
David Fetter wrote:
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.
ISTM that "uninstall foomodule" will be a whole lot nicer.
If we record all the objects that the module contains, then we would
just drop them.
The module could involve one schema, or several schemas, or none.
Maybe that's the "something big".
I think individual schemas is nicer, since it has helped me getting around
these problems for years now, while module support is still vaporware.
However, I am looking forward to your patch. :-)
Perhaps you have missed the WIP patch for module install/uninstall that
has already been submitted (not by me, by Tom Dunstan).
Tom Lane has already pointed out why the schema idea is bad. I agree
with every word he wrote.
BTW, I am suspecting part of your support will be giving pg_dump -m and -M
flags to control dumping or ignoring of specific modules?
s/your/his/. Possibly.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
