FAQ

On 28 June 2013 17:17, Tom Lane wrote:

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.

--
  Simon Riggs http://www.2ndQuadrant.com/
  PostgreSQL Development, 24x7 Support, Training & Services

Search Discussions

Discussion Posts

Previous

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 8 of 8 | next ›
Discussion Overview
grouppgsql-general @
categoriespostgresql
postedJun 28, '13 at 12:45p
activeJun 28, '13 at 4:57p
posts8
users4
websitepostgresql.org
irc#postgresql

People

Translate

site design / logo © 2017 Grokbase