WIP: shared dependencies

Hackers,

Here is a work-in-progress patch regarding the shared dependencies idea
I mentioned.  I welcome feedback on it.  Also I'd like suggestions on
the informational messages and what would useful behavior be.

For example, right now when there's an attempt to drop an user that has
objects on some other database, a complaint is emitted indicating the
number of objects.  We cannot describe them (we could only give class Id
and Oid, but not names, for example).  Also, if the user owns objects on
the current database, those are described.  Finally, an error is raised.
What should these messages say?

NOTICE: in database foo, 10 objects
NOTICE: in this database: operator +(integer, integer)
NOTICE: in this database: table foo
NOTICE: in this database: type foo
NOTICE: in this database: index foo_pkey
(etc)
ERROR: user cannot be dropped, owns objects

What about cascading the drop to the objects that are owned?  Is that a
good idea?  Of course, it would only work with local objects (and if
there's any remote objects, the user could not be dropped at all ... how
about offering a "drop everything this user owns on the current
database" command?)

There are still bugs, like the spurious entry that I mentioned in a
pgsql-bugs post, but I think this at least shows that the concept is
sound.


Some side effects of implementing this:
1. it's trivial to know what tablespaces a database use, and vice versa.
2. no more unowned objects because the owner was dropped, even in remote
databases.
3. the code to drop a user is simplified because pg_database doesn't
have to be scanned.
4. maybe it could be used to facilitate database creation (the part
about copying tablespaces from the template).


Comments are welcome.

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
Syntax error: function hell() needs an argument.
Please choose what hell you want to involve.