Currently, if you do DROP something RESTRICT where there are multiple
levels of dependencies on the "something", you get re****ts 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 re****ted 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 re****ts 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@[EMAIL PROTECTED]
)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
|
