Stephan Szabo wrote:
>
> There's a message on -general about a possible
> problem in the deferred RI constraints. He was doing a
> sequence like:
> begin
> delete
> insert
> end
> and having it fail even though the deleted key was back in
> place at the end.
Isn't that (delete and reinsert the same PK) what the standard means with "triggered data change
violation"?
It is a second touching of a unique matching PK. And in this case the standard doesn't define a behaviour,
insteadit says you cannot do so.
In the case of reinserting a deleted PK, does the new PK row inherit the references to the old PK row? If so, an
ONDELETE CASCADE must be suppressed - no?
If I'm right that it should be a "triggered data change violation", the problem is just changing into
onewe have with delete/reinsert in the ON DELETE CASCADE case. Haven't tested, but the current implementation
shouldn'tdetect it.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #