Currently, if you do DROP something RESTRICT where there are multiple levels of dependencies on the "something", you get reports that might look about like this:
NOTICE: x depends on something NOTICE: y depends on x NOTICE: z depends on y that is, you can trace the chain of reasoning for each deletion. However, we don't do that in CASCADE mode; you'll just see NOTICE: drop cascades to x NOTICE: drop cascades to y NOTICE: drop cascades to z I'm working on revising the DROP dependency logic as sketched here: http://archives.postgresql.org/pgsql-hackers/2008-05/msg00301.php and I'm realizing that it's going to be quite expensive to maintain the old NOTICE style for RESTRICT, because we aren't emitting the notices on-the-fly anymore, but only after we've finished recursing to find all the objects to delete; we'd have to save about twice as much state to remember which object was the immediate predecessor of each victim. And the old behavior was always a bit indeterminate anyway because there could be multiple dependency paths, and which one got reported as the deletion cause would be happenstance. So what I'd like to do about it is just use the CASCADE style all the time. Thoughts? BTW, it would now be possible to do something like what the shdepend code does, and stuff all these reports into the DETAIL field of a single message, instead of emitting them as separate notices. Any feelings pro or con about that? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
