Tom Lane wrote:
> 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?
>
Seems like the best approach to me. There's nothing more annoying than
fixing errors one at a time, just to see what the next one is.
It would be nice if the recursive dependency checking function was
available as an end user function too, so you could analyze dependencies
before even trying to drop something, or even just to understand a
database schema you've inherited from someone else.
Joe
