On 07/03/2013 3:14 PM, Nico Williams wrote:
On Thu, Mar 7, 2013 at 12:53 PM, Ryan Johnson
<ryan.john...@cs.utoronto.ca> wrote:
Meanwhile, though, I'd be delighted if column affinity, cast(), implicit
conversions performed by arithmetic operations, check(), and triggers all
behaved the same way, with the current behavior of column affinity probably
the least surprising/troublesome. Right now those five operations have four
different behaviors to keep track of.
I think there's just two type conversion behaviors: implicit type
conversions and CAST.
2
CHECK applies to values w/o any conversions (I
consider this a good thing),
1
affinity applies at various times and is
really a property of values derived from their sources' type affinity
(this is odd, but really a consequence of SQLite3's dynamic typing
design).
2+ (probably 4+, but let's be conservative)
Triggers don't have any special role here, save that BEFORE triggers
get values after implicit type conversions.
1 (thank goodness BEFORE and AFTER at least match behavior, even if the
underlying source of data differs slightly)
This one I tend to think
is a problem, because one cannot implement CHECK via equivalent
TRIGGERs, and the ability to add/modify table constraints by using
triggers instead is kinda nice given the inability to change
table/column constraints after a schema is set.
You just enumerated at least five different behaviors to worry about if
you might get a string or real where you expected an int.
I rest my case.
Ryan
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
