On Wed, 22 Feb 2017, Richard Hipp wrote:
CHECK constraint failures are suppose to be exceedingly rare. Elaborate error messages that pinpoint the problem are possible, but they increase the library complexity and footprint unnecessarily. In the rare event that you encounter a CHECK constraint failure, you can go back and figure out which constraint and which row is at fault using ordinary queries.
In my world, constraint failures are common rather than exceedingly rare. We made the decision that the database should validate all of its inputs as much as possible (including by using extension functions) and do not depend much on intermediate wrappers to do validation. It is pretty normal that the program or person violating the constraint is not very aware of the rules.
Due to the extreme weakness of sqlite when it comes to reporting constraint failures, we use an approach where table rows are updated one by one so that we can know which table row update failed. This causes other issues since whole-row or inter-table consistency checks may temporarily fail.
Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
