-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Darren Duncan wrote: > 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,
I might have misunderstood you. Do you really mean that a new SQLite version should enforce the types with 'UNIVERSAL' meaning any? Do you really expect everyone to have to upgrade their database schemas for this? > shorthand for an appropriate CHECK constraint, Now I am even more confused. There is this alleged group of people out there who need type enforcing but are somehow unable to put in CHECK constraints (which also let you addition stuff like range checks and other restrictions on values), so the rest of us would have to start littering our schemas with 'UNIVERSAL' to cater for them? I have yet to see a clear demonstration of two things: Why developers who want particular type/value constraints are unable to just go ahead and use constraints? Why developers who want 'strong types' don't realise that modulo type affinity you get out what you put in so don't put in "wrong" types! In short what problem actually needs to be solved and what is wrong with the existing tools for those who have the problem? Roger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrqlEEACgkQmOOfHg372QTCPACgkdvchMq2NzAU7n4cSKXABUNF YGMAn3buLfY4gfVoEeyeTYGA2UC1I4dL =3FL+ -----END PGP SIGNATURE----- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
