Simon Riggs <simon@2ndQuadrant.com> writes:
> We claim conformance to the standard on this.
Not really. The fact that we do RI actions via triggers is already not
what the spec envisions. As an example, it's well known that you can
subvert RI actions entirely by installing triggers on the target table
that make the RI actions into no-ops. It would be difficult to justify
that behavior by reference to the standard, but we leave it like that
because there are effects you really couldn't get if RI actions were
somehow lower-level than triggers. (Simple example: if you have a
business rule that updates on a table should update a last-modified
timestamp column, you might wish that updates caused by an ON UPDATE
CASCADE action did that too.)
> Should we have a parameter to define precedence of RI checks?
That seems like a recipe for breaking things. Apps already have the
ability to control whether their triggers fire before or after the RI
triggers; changing the rule for trigger firing order is going to break
anybody who's depending on that. I'm inclined to leave well enough
alone here --- especially given that, AFAIR, this is the first complaint
of this sort in the fifteen years or so that PG's RI actions have worked
this way.
regards, tom lane