Re: Changes to not deferred FK in 8.0.3 to 7.4?

Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> writes:
> On Mon, 18 Jul 2005, Tom Lane wrote:
>> I don't see why.

> Except that before I think the order would have looked like (for 1 row)
> Originating Action
> Trigger A on originating table that does update
> Trigger B on originating table that does update
> Trigger A1 caused by A
> Trigger B1 caused by B

> I think now it acts like:
> Originating Action
> Trigger A on originating table that does update
> Trigger A1 caused by A
> Trigger B on originating table that does update
> Trigger B1 caused by B

Ah, of course. So that could explain Janning's difference in results
without having to assume any rearrangement from pg_dump (not but what
we shouldn't take a second look at pg_dump's behavior anyway).

>> Do you think that's enough, or do we need to add more mechanism to
>> ensure that even non-deferred constraint checks fire after all
>> referential actions are complete?

> I think that's probably enough for now. We probably will need to do
> something, but since we still haven't managed to work out all of these
> timing problems, I think it needs a bunch of going over the spec before
> trying to actually do any changes.

Agreed, this doesn't seem like an area for hasty solutions.

The short-term answer for Janning is definitely to make his check
constraints deferred, but we should look at whether our current ordering
of non-deferred checks is really per spec or not.

regards, tom lane