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:
http://www.postgresql.org/mailpref/pgsql-hackers
