| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
| Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Copy-pasto in the ExecForeignDelete documentation |
| Date: | 2016-02-03 15:13:47 |
| Message-ID: | CA+TgmoaZGoxVX2w627CK9OSLi88_7HdU3nNncAcqA0mCkt+5wA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Feb 1, 2016 at 5:26 AM, Etsuro Fujita
<fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> I don't think the data is referenced by the AFTER ROW DELETE triggers.
Why do you think that? And why would DELETE triggers be different
from UPDATE triggers, which do something similar?
I looked up the history of this code and it was introduced in
7cbe57c3, which added support for triggers on foreign tables. Noah
did that commit and he's rarely wrong about stuff like this, so I
suspect you may be missing something. One thing to consider is
whether the version of the row that finally gets deleted is
necessarily the same as the version originally selected from the
remote side; e.g. suppose the remote side has triggers, too.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Steele | 2016-02-03 15:37:32 | Re: PostgreSQL Audit Extension |
| Previous Message | Robert Haas | 2016-02-03 14:57:00 | Re: checkpoints after database start/immediate checkpoints |