"Ann W. Harrison" <aharrison@...> wrote:

>
> 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.

Done in v2.0.

> 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.

Correct.

> 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...

Reading the spec, I have a suspicion that all database constraints should be
checked after any statement. I'm not able to prove that though.

The only real inconsistency I see is that constraints should _not_ be
checked at the per row basis. Instead of doing:

IF (NOT NEW.FIELD = 0)
ABORT;

during row assignment, we're required to perform:

IF EXISTS ( SELECT * FROM T WHERE NOT FIELD = 0 )
ABORT;

at the end of the insert/delete statement.

> 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?

It makes lots of sense.


Dmitry