Simon Riggs <simon@xxxxxxxxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
