Stephan Szabo <sszabo@xxxxxxxxxxxxxxxxxxxxx> 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
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your
message can get through to the mailing list cleanly
