From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Thom Brown <thombrown(at)gmail(dot)com> |
Cc: | Grzegorz Jaśkiewicz <gryzman(at)gmail(dot)com>, adrian(dot)klaver(at)gmail(dot)com, pgsql-general(at)postgresql(dot)org |
Subject: | Re: unexpected effect of FOREIGN KEY ON CASCADE DELETE |
Date: | 2010-06-23 18:31:02 |
Message-ID: | 25742.1277317862@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Thom Brown <thombrown(at)gmail(dot)com> writes:
> Yes, I'm still not exactly sure why it's seeing uncommitted changes. :/
Because it's all one transaction. A transaction that couldn't see its
own changes wouldn't be very useful.
I think what the OP is unhappy about is that he imagines that the ON
CASCADE DELETE action is part of the original DELETE on the primary-key
table. But it is not: per SQL spec, it is a separate operation
happening after the original DELETE. (In fact, it might be quite a lot
after the original delete, if you have the FK constraint set as
deferred.) The trigger on the referencing table fires before the actual
delete of the referencing row, but it's going to see the original DELETE
statement as already completed, because it was a previous operation
within the current transaction.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2010-06-23 19:07:51 | Re: unexpected effect of FOREIGN KEY ON CASCADE DELETE |
Previous Message | Tom Lane | 2010-06-23 18:08:26 | Re: what is the meaning of Datum? |