Re: Deferrable vs. Not-Deferrable Constraints

From: Howard J. Rogers <howardjr2000_at_yahoo.com.au>
Date: Fri, 7 Feb 2003 02:20:17 +1100
Message-ID: <bWu0a.42203$jM5.106103@newsfeeds.bigpond.com>

"JustAnotherDBA" <jadba_at_bellsouth.net> wrote in message news:MFl0a.1418$Cl2.402_at_FE04...
> Thanks for all the comments.
>
> Just to clarify, when we do change our constraints, I will want to keep
the
> current default behavior where the INSERT generates an error if the
> constraint is violated.
>
> So, we will recreate the constraints with the deferrable option, but also
> with the initially immediate option too.

Perfect. Thoroughly recommended.

>
> Anyway, I do like the option of turning off constraint checking until I
> commit . This could be useful during activity like doing data changes
(mass
> load or fixing a problem some app caused or for whatever reason) of
> parent/child table data.
>
> Seems like this setup should be a default behavior especially when there
is
> no difference with the current default behavior UNTIL you do the set or
> alert session command .
>
> Or, am I missing something ?

Only that deferrable constraints were only invented in 8.0, so there's a lot of old apps still around that would (probably) break if they ever changed the default. Also, since there's no performance difference between deferrable/non-deferrable, and also no security issue involved, I guess they deem the costs of such a change (in terms of broken apps) would outweigh the benefits. The same can't be said of (for example) o7_dictionary_accessibility or LMT/DMT.

Regards
HJR Received on Thu Feb 06 2003 - 09:20:17 CST