Am 11/17/2015 11: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.
A good explanation. It's faster and need lesser memory. Although, the plea stays. Obviously, the name of the constraint would add value to the message. You made crystal clear, that we can't have both at once: fast / less memory and helpful constraint failed message. The way out may be ly in the words "at once". In case of a 'FOREIGN KEY constraint failed' I'm temporarily fine with a not so fast and memory efficent sqlite, as long, as it helps me, to understand the situation more quickly.
