Re: AFTER triggers and constraints

On 28 June 2013 17:17, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Simon Riggs <simon(at)2ndQuadrant(dot)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