First, we're in general agreement, I think, on check
constraints whose test evaluates to NULL. That condition
should not block the action and we should change the
code generated for the check constraint triggers in V2
and Vulcan.

Second, we're in general agreement, I think, on the
current state of the evaluation of check constraints
as user-context triggers. It works correctly for
constraints limited to a single row, but not for
multi-row constraints or cross-table constraints.

We're nowhere yet on cross-table constraints. Here
are some facts:

1) Firebird and InterBase have supported cross table
constraints since V4 using SQL syntax and earlier in
GDML.

2) Cross table constraints are in wide use and removing
them will be unpopular.

3) The 2003 SQL standard appears to allow cross table
check constraints.

4) In Firebird, check constraints are tested on insert
and update to insure that the constraint is satisfied
for the current row.


Because constraints are executed in the user context and
because they are not reflexive - even if rows in table A
are constrained by conditions on table B, the constraints
from A are not evaluated when changes are made to B -
it is possible, likely, simple to create a situation where
the constraint is violated.

Deferring constraints - evaluating them at commit rather
than verb time - won't solve either the problem of evaluation
in user context or the fact that they aren't evaluated when
a referenced table changes. Deferred constraints are valuable
for other reasons, but they won't get us out of our current
bind.



Among my questions are:

1) Does the standard require that check constraints be
valid at all times or only when rows of the constrained
table are altered? Probably the former...

2) Does it make sense to get V2, V1.5.3, and Vulcan out
and then have a serious talk about how constraints - row,
verb, and deferred - should be implemented?

Regards,


Ann