Re: Questions on RI spec (poss. bugs)

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 #