On Wed, Sep 08, 2010 at 10:01:48PM +0100, Andrew Wood scratched on the wall: > Because I'm writing glue code between the SQLite API and a higher level > library which provides a standard API across several DBMSs. > > In other DBMSs even if a field contains null you can still ask the API > what type it 'should' have been if something *had* been put in it. > Without this ability, I cant make SQLite work with the library. > > I don't understand the reasoning for designing SQLite weakly typed like > this, it just seems bizarre.
SQLite is not "weakly" typed. Each value has a very specific and strongly enforced type. It just happens that type assignment happens at the value level, rather than the column level. When I first came to SQLite from the client/server RDBMS world, I was somewhat shocked as well. But in the end, it really doesn't make much of a difference. Like most other languages, all forms of SQL do a significant amount of type coercion. Opening up that domain to something larger than what a traditional programmer considers a "type" doesn't really change anything. Does it really matter that -3 < 5.35667 < 'abc' ? As long as you have a solid ordering and conversion rules, there are rarely surprises. And if someone really cares, they can add CHECK constraints-- which they should be doing anyways if they're that paranoid about type-domain checking. Simply limiting a value to an integer (or whatever) is no more or less "safe" unless you further limit things to a task-specific sub-domain of that type. I also have to say that handling NULLs as a value-less type is a very clean and handy model. -j -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "Intelligence is like underwear: it is important that you have it, but showing it to the wrong people has the tendency to make them feel uncomfortable." -- Angela Johnson _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users