Jos, I see your point but another way to look at it is that PRAGMA foreign_keys=0/1 changes the definition of what constitutes a legal/consistent state of the database, thus it makes sense that behavior of check_integrity PRAGMA would change accordingly.
Thanks, - Levi ----- Original Message ----- From: sqlite-users@sqlite.org To: sqlite-users@sqlite.org At: Dec 12 2012 16:01:25 > This seems like a reasonable request. And while we are at > it, we will likely also verify UNIQUE and CHECK constraints too. > > PRAGMA quick_check is still available for users who do not > want to take the extra overhead of verifying UNIQUE, CHECK, > and foreign key constraints. > > Does anybody know of any reason why we should not do this? If I understand correctly PRAGMA integrity_check checks for database corruption. A database is corrupt if it is not in a state as documented and intended by the author of SQLite. When you enable foreign keys *after* you insert records, no guarantee is given by SQLite that the foreign key constraints are fulfilled. This may not be what most users would want or expect but it certainly not a corrupt database by SQLite standards. I think the distinction between these two cases should remain clear and the current integrity_check should not mix them. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
