---------- Original Message -----------
From: Jim Starkey <jstarkey@...>

> The smart thing is to validate everything at statement time and
> re-evaluate only the failures at commit time. But deferring blocking
> for validation requests until commit time maximizes parallelism.

------- End of Original Message -------

Depends on the constraint type. If you allow multi-row ("there can be at most
50 rows of this description", "no two rows can have overlapping date ranges")
or multi-table constraints, it may be more efficient to just wait and do it
once, at commit, or earlier if the client can hint that it's done and ready for
validation. The same might apply to those users who insist on having code that
updates the same row repeatedly inside the transaction, and don't necessarily
care to have row-level constraints verified every time.

(I implement this manually with triggers/temporary tables/procedures/on-commit
triggers, with the ability to call the validation procedure ad-hoc, and in the
process clear the temporary table if it all checks out. But that's using
triggers for constraints, which works, but isn't semantically clear; I wouldn't
mind seeing the database support those as such. Postgres has on-commit
constraints instead of the triggers; of the two, I'd still take the Firebird
approach.)

-Philip