> It is a substantial change (basically a complete rewrite of the entire
> foreign key constraint mechanism) which would negatively impact both
> space and performance.
I think the argument is fallacious.
Don't keep the bag, keep only one integer ID of the first failed
constraint. That's all the users mostly care about.
// --- pseudo-code at the point of failure ---
if (!...check if constraint failed...) {
// fast branch: normal stuff when constraint is satisfied, not
impacted by the change at all
} else { // constraint failed
// slow branch: failure is normally unexpected, this is executed very
rarely
cntFailed++;
if (!savedFailedID) savedFailedID = currentFailedID; // the only
added line is
}
You only need to modify the slow branch. This has practically zero
performance impact, in any case it is exactly zero for the non-failure
operation.
Yuri
