Roger Binns wrote: >> In fact this support might even be easier as it may only require >> enhancements to >> the SQL parser, which would generate VM opcodes like for a CHECK constraint, >> unless further work is done to optimize for the presented cases, or to >> enhance >> semantics. > > It has been stated in several places that the increasing items in the parser > will lead to various fields needing to go to the next size up which would > increase memory consumption. There is also the whole backwards > compatibility angle - what would happen if the database was loaded into an > older version of SQLite which then ignored this whole UNIVERSAL thing > allowing "wrongly" typed data to be inserted?
An added type name like UNIVERSAL would be completely backwards compatible because, as far as I recall, if SQLite currently sees a type name it doesn't recognize, then the column has no affinity and will accept any value, so same behavior. And so then, for older systems using that keyword would be effectively a documentation convention. But on a newer SQLite that implements the stronger typing support I proposed, when that feature is active then columns with declared types like INTEGER/etc would enforce that only values of that type are stored there, like it is a shorthand for an appropriate CHECK constraint, and so marking a column UNIVERSAL in this situation is explicitly stating that, in the system where type constraints are enforced, that column may take any value. -- Darren Duncan _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
