Hello,

> While I agree that true database constraints would be good, and deferred

constraints make sense,

> this also means that statements/triggers/procedures can no longer trust

that the data being

> processed will match the constraints. So long as you're in the middle of a

transaction, all bets

> are off. It's at least something people should be warned about.
>
> The other thing is locking. If FK's are only checked at commit-time, is

there any way we could

Not ALL constraints should be deferred. The default would be "immediate".

There are, however, plenty of reasons to create "deferred" constraints if
you
would like the engine to keep your database consistent.

Also, in procedures, it would -sometimes- be easier to be able to shuffle
with data and keep things consistent at commit time compared to having
to keep track of what you're changing exactly in a certain order.

Think of constraints that say things like:
- if there's a package of B at location A, only 1 record in table Z can
exist.

Etc... These are business constraints that could be kept on the database,
where, IMO, they belong if this is a requirement for valid data.


With regards,

Martijn Tonies
Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL
Server.
Upscene Productions
http://www.upscene.com