FOREIGN KEY: difference between NOT DEFERRABLE and INITIALLY IMMEDIATE

Started by Gabriel Fernandezover 24 years ago3 messagesgeneral
Jump to latest
#1Gabriel Fernandez
gabi@unica.edu

Hi,

What's the difference between NOT DEFERRABLE and INITIALLY IMMEDIATE for
a FOREIGN KEY specification ?

It seems they are both defining the same: the moment the constraint will
be checked: the instant the statement is processed or the end of
transaction.

Thanks,

Gabi :-)

#2Stephan Szabo
sszabo@megazone23.bigpanda.com
In reply to: Gabriel Fernandez (#1)
Re: FOREIGN KEY: difference between NOT DEFERRABLE and

On Tue, 4 Sep 2001, Gabriel Fernandez wrote:

Hi,

What's the difference between NOT DEFERRABLE and INITIALLY IMMEDIATE for
a FOREIGN KEY specification ?

It seems they are both defining the same: the moment the constraint will
be checked: the instant the statement is processed or the end of
transaction.

Well, at start. With initially immediate you can use SET CONSTRAINTS to
change it on the fly back and forth from deferrable to not. NOT
DEFERRABLE means you cannot do so.

#3Jan Wieck
JanWieck@Yahoo.com
In reply to: Gabriel Fernandez (#1)
Re: FOREIGN KEY: difference between NOT DEFERRABLE and INITIALLY

Gabriel Fernandez wrote:

Hi,

What's the difference between NOT DEFERRABLE and INITIALLY IMMEDIATE for
a FOREIGN KEY specification ?

It seems they are both defining the same: the moment the constraint will
be checked: the instant the statement is processed or the end of
transaction.

Thanks,

Gabi :-)

Not exactly.

DEFERRABLE means, that the application can issue a

SET CONSTRAINTS { <name_list> | ALL } { DEFERRED | IMMEDIATE }

whithin a transaction to change the actual behaviour of the
named or ALL deferrable constraints until either COMMIT or a
subsequent SET CONSTRAINTS. Setting a currently deferred
constraint to IMMEDIATE explicitly causes the so far
collected checks to be done at SET time.

INITIALLY { DEFERRED | IMMEDIATE } thus only controls the
initial state of the constraints checking behaviour at the
beginning of the transaction.

INITIALLY DEFERRED implicitly causes a constraint to be
DEFERRABLE.

Needless to say that NOT DEFERRABLE and INITIALLY DEFERRED
are mutually exclusive.

All this gives your application fine control about "when"
constraints get checked, while the database is still in full
charge of the referential integrity. If you have setup all
your constraints beeing INITIALLY DEFERRED, your application
can do the following:

BEGIN TRANSACTION;
-- do some stuff
SET CONSTRAINTS ALL IMMEDIATE;
SET CONSTRAINTS ALL DEFERRED;
-- do more stuff
SET CONSTRAINTS ALL IMMEDIATE;
SET CONSTRAINTS ALL DEFERRED;
-- do final stuff
SET CONSTRAINTS ALL IMMEDIATE;
COMMIT TRANSACTION;

The only places, where referential integrity errors can raise
now are the "SET ... IMMEDIATE" queries.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com