Re: unexpected effect of FOREIGN KEY ON CASCADE DELETE

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

In response to

Responses

Browse pgsql-general by date

  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?