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, instead it 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 ON DELETE
CASCADE must be suppressed - no?
If I'm right that it should be a "triggered data change
violation", the problem is just changing into one we have
with delete/reinsert in the ON DELETE CASCADE case. Haven't
tested, but the current implementation shouldn't detect it.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== [EMAIL PROTECTED] #
