> The issue for something like a data-time field is how would you indicate that a field is a data-time field. Due to backwards compatibility it can't use the term data or time to trigger that use, as existing applications use that and expect a different result, based on published and promised rules.
I don't see a huge problem here. Does the database file have a version number indicating which version the file has been created with? If so, newer SQLite libraries could easily emulate the old-style behavior by just checking this version number. Alternatively, one could introduce a pragma statement, say PRAGMA emulation=ver, that could default to 3.30 (or whatever) now and which doesn't change at all (or will at least always be some years behind the most current version) and which tells the library to behave exactly as in version <ver>. This would allow changing modes without breaking existing applications. One step more could be storing <ver> in the database as well, using the version number enabled upon database creation. This way, one would have a mechanism that could eliminate "cannot be done due to backward compatibility" once and forever :) _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users