Re: User-friendliness for DROP RESTRICT/CASCADE - Mailing list pgsql-hackers

From Rod Taylor
Subject Re: User-friendliness for DROP RESTRICT/CASCADE
Date
Msg-id 1025135506.1123.151.camel@jester
Whole thread Raw
In response to Re: User-friendliness for DROP RESTRICT/CASCADE  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: User-friendliness for DROP RESTRICT/CASCADE  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
On Wed, 2002-06-26 at 22:30, Tom Lane wrote:
> Joe Conway <mail@joeconway.com> writes:
> > 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.
> 
> It'd be a pretty trivial exercise to build something that looks at the
> pg_depend entries and generates whatever kind of display you want.
> 
> David Kaplan reminded me that there is another UI issue to be
> considered: when we *are* doing a DROP CASCADE, should the dropped
> dependent objects be reported somehow?  As it stands, Rod's patch emits
> elog(NOTICE) messages in this case, but I am wondering whether that will
> be seen as useful or merely annoying chatter.

If the notices about implicit drops (triggers on tables, etc.) has been
found to be useful in both creation and destruction then I would assume
that this information would be wanted as well.

If the above information has not been found to be useful in the past,
then I would expect it to continue as chatter.

Personally, I find it to be chatter and turn off NOTICES in general, but
believe it to be consistent with similar messages in the past.





pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Why I like partial solutions
Next
From: Rod Taylor
Date:
Subject: Re: Postgres idea list