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. The rest is related but orthogonal and -to my mind- unavoidable: CHECK applies to values w/o any conversions (I consider this a good thing), 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). Triggers don't have any special role here, save that BEFORE triggers get values after implicit type conversions. 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. Nico -- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
