On 2016/02/04 0:13, Robert Haas wrote:
On Mon, Feb 1, 2016 at 5:26 AM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.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?

As for the UPDATE case, I think local AFTER ROW UPDATE triggers have to reference the data since a BEFORE trigger on the remote server might change the to-be-updated version of the row originally assigned. But as for the DELETE case, I was not thinking so.

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.

Maybe I'm missing something, but I was thinking that version should be the same as the version originally selected from the remote server; the delete would be otherwise discarded since the updated version would not satisfy the delete's condition, something similar to "ctid = $1" in the postgres_fdw case, during an EvalPlanQual-like recheck on the remote server.

Best regards,
Etsuro Fujita

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to