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.)
I'm certainly happy with the way our RI works, for those reasons and others.
This was just a matter of altering the precedence since applications written to the standard won't work right, not about altering the level at which RI acts.
> 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.
It won't break anything because it would be a parameter, not a change in default behaviour.
If your completely set against this then I'll add a note to our conformance statement.
