User-friendliness for DROP RESTRICT/CASCADE

I have been reviewing Rod Taylor's pg_depend patch, which among other
things adds SQL-compliant DROP RESTRICT/CASCADE syntax and prevents
you from dropping things that other things depend on, as in ye olde
novice error of dropping a function used by a trigger.

As submitted, the patch gives elog(ERROR) as soon as it finds any
dependency, if you've specified (or defaulted to) DROP RESTRICT
behavior.  This means you only find out about one randomly-chosen
dependency of the target object, and have no easy way to know what
else might get dropped if you say DROP CASCADE.

I am thinking of changing the behavior so that it reports *all* the
dependencies via NOTICEs before finally failing.  So instead of this:

DROP TYPE widget RESTRICT; -- fail
ERROR:  Drop Restricted as Operator <% Depends on Type widget

you might see this:

DROP TYPE widget RESTRICT; -- fail
NOTICE:  operator <% depends on type widget
NOTICE:  operator >% depends on type widget
NOTICE:  operator >=% depends on type widget
ERROR:  Cannot drop type widget because other objects depend on itUse DROP ... CASCADE to drop the dependent objects
too

Any objections?

Also, would it be a good idea to make it *recursively* report all
the indirect as well as direct dependencies?  The output might get
a little bulky, but if you really want to know what DROP CASCADE
will get you into, seems like that is the only way to know.

To work recursively without getting into an infinite loop in the case of
circular dependencies, we'd need to make DROP actually drop each object
and CommandCounterIncrement, even in the RESTRICT case; it would rely on
rolling back the entire transaction when we finally elog(ERROR).  This
might make things a tad slow, too, for something with many dependencies
... but I don't think we need to worry about making an error case fast.

Comments?
        regards, tom lane