"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> We discussed it to the point of consensus, and Tom wrote a patch
> to implement that. Testing in my shop hit problems for which the
> cause was not obvious. I don't know whether there is a flaw in
> the designed approach that we all missed, a simple programming bug
> of some sort in the patch, or pilot error on this end.
It's looking like the last of those. The problem was in BEFORE
DELETE triggers which, for example, would check that there were the
expected child records (throwing an error if they were missing)
right before deleting them. When the "reissue the DELETE and then
RETURN NULL" trick was used to avoid errors with this patch, the
trigger would fail the second time through. Of course, such
triggers were more than a bit silly and clearly The Wrong Thing To
Do in general. I don't know how widespread such practice is, but it
will need to be fixed where it exists in order to use the proposed
patch and related workaround for "cascade delete"-like triggers.
Before someone says that foreign keys should just be used, I want to
point out the "-like" above. In my experience, for about every ten
cases where a declarative constraint like UNIQUE or FOREIGN KEY can
cover a business rule, there is about one that is logically very
similar to such a declarative constraint but just different enough
that it must be implemented in custom code. Jeff Davis has been
improving that ratio, but I doubt that the issue will ever disappear
entirely.
At any rate, I think we might want to apply Tom's patch for this
while 9.3 is still early in development, to see what else might
shake out from it while there is still plenty of time to fix any
issues. It's now looking good from my perspective.
-Kevin