Re: Odp: PD: triggered data change violation on relation

On Mon, 3 Sep 2001, Tom Lane wrote:

> Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> writes:
> > This was a mistake in the interpretation of the spec (modification of
> > the same key row referenced by a foreign key constraint in the same
> > statement more than once is an error is how we believe the spec meant
> > it, but there's a case where they mention transaction and it got
> > misinterpreted). I don't think anyone's permanently fixed it yet, but
> > making the check disappear involves commenting out the two blocks that
> > throw the message in backend/commands/trigger.c.
>
> Would it be better to just do that until a proper solution is
> implemented? What is the downside of not making any check?

I believe the intention of the check was to prevent a case from
occurring where you update a value and then have a cascade constraint
change it for a second time if you have some kind of recursive
constraint structure. I think this could occur if you had something
like TableA.id references TableB.id cascade and then TableB.id
references TableA.id set default, then when you changed tableb.id,
the tablea.id would change which would cause the tableb.id to be
set to the default (but should error I think).

This is probably a smaller failure case however, given it took
some time for me to come up with a good failure, and I think more
people are hitting the current problem, so I'd vote for changing
it.