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). >>>> 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. Nico -- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
