Re: [sqlite] No way to check for CHECK constraint violations a posteriori

2017-02-27 Thread Bob Friesenhahn
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

Re: [sqlite] No way to check for CHECK constraint violations a posteriori

2017-02-22 Thread Dominique Devienne
On Wed, Feb 22, 2017 at 6:09 PM Dominique Devienne wrote: > On Wed, Feb 22, 2017 at 5:50 PM, Richard Hipp wrote: > > On 2/22/17, Dominique Devienne wrote: > > > > > > > > Could we please have the CHECK constraint name, > > > > in

Re: [sqlite] No way to check for CHECK constraint violations a posteriori

2017-02-22 Thread Dominique Devienne
On Wed, Feb 22, 2017 at 5:50 PM, Richard Hipp wrote: > On 2/22/17, Dominique Devienne wrote: > > > > Could we please have the CHECK constraint name, > > in addition to the table name, in case of a failure? > > > > Pushing my luck a little bit: any chance to

Re: [sqlite] No way to check for CHECK constraint violations a posteriori

2017-02-22 Thread Richard Hipp
On 2/22/17, Dominique Devienne wrote: > > Could we please have the CHECK constraint name, > in addition to the table name, in case of a failure? > > Pushing my luck a little bit: any chance to be able to pinpoint the > offending rows, similar to how foreign_key_check does it?

Re: [sqlite] No way to check for CHECK constraint violations a posteriori

2017-02-22 Thread Dominique Devienne
On Wed, Feb 22, 2017 at 4:47 PM, Richard Hipp wrote: > On 2/22/17, Dominique Devienne wrote: > > Neither {{pragma integrity_check}} nor {{pragma foreign_check_check}} > > checks CHECK constraints. > > That is now fixed on a branch. I am still testing the

Re: [sqlite] No way to check for CHECK constraint violations a posteriori

2017-02-22 Thread Richard Hipp
On 2/22/17, Dominique Devienne wrote: > > PS: Also note that {{pragma integrity_check}} (or quick_check) and {{pragma > foreign_check_check}} differ in behavior, one return ok, the other nothing. > Ideally they'd be consistent. > Probably they should have been. But that is

Re: [sqlite] No way to check for CHECK constraint violations a posteriori

2017-02-22 Thread Simon Slavin
On 22 Feb 2017, at 3:47pm, Richard Hipp wrote: > On 2/22/17, Dominique Devienne wrote: >> Neither {{pragma integrity_check}} nor {{pragma foreign_check_check}} >> checks CHECK constraints. > > That is now fixed on a branch. I am still testing the changes

Re: [sqlite] No way to check for CHECK constraint violations a posteriori

2017-02-22 Thread Richard Hipp
On 2/22/17, Dominique Devienne wrote: > Neither {{pragma integrity_check}} nor {{pragma foreign_check_check}} > checks CHECK constraints. That is now fixed on a branch. I am still testing the changes prior to merging onto trunk. -- D. Richard Hipp d...@sqlite.org

Re: [sqlite] No way to check for CHECK constraint violations a posteriori

2017-02-22 Thread Hick Gunter
A CHECK constraint is just a special trigger that allows you to raise an error and only runs on INSERT and UPDATE. It has nothing to do with internal database structure (pragma integrity_check) or with foreign keys (pragma foreign_key_check; you have to enable foreign key checking first

[sqlite] No way to check for CHECK constraint violations a posteriori

2017-02-22 Thread Dominique Devienne
Neither {{pragma integrity_check}} nor {{pragma foreign_check_check}} checks CHECK constraints. Given that there's {{pragma ignore_check_constraints = 1}} which allows to bypass CHECK constraints, that seems like a surprising oversight. I even tried {{pragma ignore_check_constraints = 0}} in