Re: User-friendliness for DROP RESTRICT/CASCADE

From: Joe Conway <mail(at)joeconway(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org, Rod Taylor <rbt(at)zort(dot)ca>
Subject: Re: User-friendliness for DROP RESTRICT/CASCADE
Date: 2002-06-26 18:10:25
Message-ID: 3D1A0391.4030205@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dave Cramer 2002-06-26 18:17:58 Re: Postgres idea list
Previous Message Josh Berkus 2002-06-26 18:08:31 Re: Postgres idea list