On Fri, Oct 30, 2009 at 7:14 AM, P Kishor <punk.k...@gmail.com> wrote: > Actually, there can be one bad effect of Darren's suggestion, now that > I think of it, and that would be for those who don't care for strong > typing. They will end up getting strong typing for all non-UNIVERSAL > columns whether they like it or not, whether they expect it or not, > unless there is a pragma as well to just disable strong typing > completely.
If someone were to implement this, the appropriate place is not in the schema definition, the appropriate place is as a PRAGMA, perhaps PRAGMA strong_typing. When defined, schema would be transformed at table creation time to add the appropriate checks. With this implementation you could also more easily compile the support out of SQLite, because it's not a change to syntax, it's a change to how tables are created, so when compiled out you get exactly the SQLite you had before the code was added. Another alternate might be "CREATE PEDANTIC TABLE xxx", because then the only footprint is that additional keyword, though I think PRAGMA is a lot more clear for optional features. That said, I agree with others that the feature is mis-guided. If you think that a column should be an integer, then when you store things to that column use sqlite3_bin_int(). As an application developer, you should NEVER let users define the type of data stored in your database in the first place, you should ALWAYS explicitly validate their input. You could use this kind of type-checking to keep people developing against your schema from doing bad things, but given the nature of SQLite it's hard to see how useful that would be in practice (versus a client-server system where many people may be sharing the same production database instance). -scott _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
