On 28 June 2013 17:17, Tom Lane <t...@sss.pgh.pa.us> wrote: > Simon Riggs <si...@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. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
