I think there's a solution for this, which is, loosely, to run the constraint tests twice, conditionally. That is, run it the current fast way as usual, and then only if there is a failure, run the tests again the slower way that keeps track of things so we know where the failure is. Since we only get the slowdown in the failure case, when the code is aborting anyway, it should be ok. The only negative then is that the code size increases somewhat, but it doesn't have to increase as much because the second run isn't to determine whether there will be a failure but to inform on a failure we already know happened. This add-on could also be a compile-time option to exclude if desired. -- Darren Duncan
On 2015-11-17 2:32 PM, Richard Hipp wrote: > On 11/17/15, Yuri <yuri at rawbw.com> wrote: >> This message always leaves the user wondering: "Which constraint?" >> >> How hard is it to add this information to the message? Is this a matter >> of memorizing the ID of the constraint, and then printing its name in >> the message? > > It is a substantial change (basically a complete rewrite of the entire > foreign key constraint mechanism) which would negatively impact both > space and performance. > > The current foreign key constraint mechanism uses a single counter. > As constraints are violated, the counter increments, and as > constraints are resolved the counter decrements. At the end, if the > counter is greater than zero then a "foreign key constraint" error is > issued. > > To provide information about which constraint(s) failed, it would be > necessary to have a bag (a list or hash table or an associative array) > of all the constraints that have been violated and then remove > elements from the bag as constraints are resolved. > > A bag takes more run-time memory than a single counter. (Maybe a lot > more, depending on how many elements it holds.) Adding an element to > a bag takes more time than incrementing a counter. (In particular, > adding an element to a bag probably involves one or more calls to > malloc().) Removing an element from a bag takes more time than > decrementing a counter. >
