Martijn Tonies wrote:

>
> What do DEFERRED constraints actually mean? When DO they start
> checking? And when don't they?

The current constraint implementation is fired when a record is inserted,
updated or deleted. There are some relationships that may need data in more
than one table to be valid. Currently, these cases can't be validated or
they would be rejected. Triggers aren't a reliable solution for this task in
multi-user environments.

AFAIK, Sybase allows deferred constraints. One changed table as seen alone
may be inconsistent at the time the operations over it are being done, but
if the change to all tables is analyzed after several operations, we can
find that we got the equivalent of an OODBMS' state change for all involved
objects, where the configuration as a whole went from one consistent state
through another consistent state, even if there were intermediate steps of
inconsistency. For a relational engine, this means all the DEFERRED
constraints must be checked at commit time. David's first example can be
assimilated to the second, if you commmit after a single statement that
produces multiple changes in a table.

C.