On 07/03/2013 12:27 PM, Nico Williams wrote:
On Thu, Mar 7, 2013 at 11:12 AM, Ryan Johnson
<ryan.john...@cs.utoronto.ca> wrote:
I would argue that, if a column has type affinity, CHECK should work with
the value that would actually get stored, not the one that was assigned.
But then you couldn't check the value that was attempted to store.
You'd be stuck with dynamic type conversions in all cases.
Is that a bad thing? Forbidding dynamic type conversions to occur at all
is very different than requiring that they always succeed if/when they
do occur, and overly strict IMO.
Besides, the check is defined to verify the column, not on the value
that came from the user. In theory you should be able to defer all
checks until the end of a transaction (for all the same reasons deferred
FK checking can be important), and that would cause a behavior change as
things currently stand (the attempted-to-store value would be long gone
by then).
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.
Ryan
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
