On 07/03/2013 1:48 PM, Nico Williams wrote:
On Thu, Mar 7, 2013 at 12:20 PM, Ryan Johnson
<ryan.john...@cs.utoronto.ca> wrote:
On 07/03/2013 1:07 PM, Nico Williams wrote:
You might defer checks, but not type conversions. In any case, I see
no value in deferring check constraints.
Anything constraining cardinality. The old example of "there must always be
three doctors on duty in the ER" comes to mind: if you check() for an exact
count, it becomes very hard to make changes to the schedule without deferred
checking.
That can't be done with a CHECK expression. I have proposed
transaction-level triggers for this sort of thing, and I have an
implementation lying around (but it's not finished, and quite rotted
by now).
Fair enough. It might be worth deferring a check until transaction end
if it allows verifying a bulk update with an efficient index probe, but
that would only be true for really expensive checks and really big bulk
updates.
Anyways, think of CHECK constraints as equivalent to BEFORE
INSERT/UPDATE triggers.
They're not equivalent. The before trigger sees only the value that was
actually stored, because it runs as a separate program after the
insert/update completes.
WAT?
Yup. I've had several emails in this thread with examples. Here's the short
version:
BEFORE INSERT/UPDATE triggers may apply after type conversions, but
not after storing the new/updated row. That's what my WAT was about
:)
Check out the vdbe generated by an insert on a table with a before
insert trigger.
Fair enough. I should have said:
They're not equivalent. The before trigger sees only the value that will
actually be stored.
Ryan
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
