Am 29.10.2009 um 14:31 schrieb Simon Slavin: > > On 29 Oct 2009, at 9:36am, John Crenshaw wrote: > >>> Consider the case of an application using an SQLite database to >>> store >>> its settings (like the Windows registry, but portable). The dynamic >>> type system is great for this. >>> >>> CREATE TABLE Settings (Name TEXT PRIMARY KEY, Value BLOB); >>> >>> Name Value >>> ----------------- --------------- >>> LogPath 'E:\log\FooApp' >>> MaxAttachmentSize 2500000 >>> LastUpdate 2455130.1125 >>> >>> Now, in the SQLite equivalent of regedit, how is it supposed to know >>> that LastUpdate is timestamp 2009-10-25 14:42:00 but >>> MaxAttachmentSize >>> is NOT the date 2132-08-31 12:00:00? Without knowledge of the >>> application that created this table, it can't. >> >> A system like this would need a type column as well. Storing dates as >> text doesn't change that, because at some level you'll still need to >> distinguish between regular text, and a date stored as text. Once you >> add a type column, it is no longer ambiguous. > > Erm ... no. You just call 'typeof()' on the value that was returned. > That tells you what type of thing it is.
Only sort of... sqlite> SELECT typeof(julianday()); real So it will tell you which of the _internal_ types it is, but since SQLite lacks an internal type for date/time, you're back to where the discussion started... You'll still need to have some sort of context for the column value that tells you what higher-level data type it represents. </jum> _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
