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
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
