(2018/08/30 21:58), Etsuro Fujita wrote:
(2018/08/30 20:37), Kyotaro HORIGUCHI wrote:
At Fri, 24 Aug 2018 21:45:35 +0900, Etsuro
Fujita<fujita.ets...@lab.ntt.co.jp> wrote
in<5b7ffdef.6020...@lab.ntt.co.jp>
(2018/08/21 11:01), Kyotaro HORIGUCHI wrote:
At Tue, 14 Aug 2018 20:49:02 +0900, Etsuro
Fujita<fujita.ets...@lab.ntt.co.jp> wrote
in<5b72c1ae.8010...@lab.ntt.co.jp>
(2018/08/09 22:04), Etsuro Fujita wrote:
(2018/08/08 17:30), Kyotaro HORIGUCHI wrote:
I spent more time looking at the patch. ISTM that the patch well
suppresses the effect of the tuple-descriptor expansion by making
changes to code in the planner and executor (and ruleutils.c), but I'm
still not sure that the patch is the right direction to go in, because
ISTM that expanding the tuple descriptor on the fly might be a wart.
The exapansion should be safe if the expanded descriptor has the
same defitions for base columns and all the extended coulumns are
junks. The junk columns should be ignored by unrelated nodes and
they are passed safely as far as ForeignModify passes tuples as
is from underlying ForeignScan to ForeignUpdate/Delete.
I'm not sure that would be really safe. Does that work well when
EvalPlanQual, for example?
I was wrong here; I assumed here that we supported late locking for an
UPDATE or DELETE on a foreign table, and I was a bit concerned that the
approach you proposed might not work well with EvalPlanQual, but as
described in fdwhandler.sgml, the core doesn't support for that:
For an <command>UPDATE</command> or <command>DELETE</command> on a
foreign table, it
is recommended that the <literal>ForeignScan</literal> operation
on the target
table perform early locking on the rows that it fetches, perhaps
via the
equivalent of <command>SELECT FOR UPDATE</command>. An FDW can
detect whether
a table is an <command>UPDATE</command>/<command>DELETE</command>
target at plan time
by comparing its relid to
<literal>root->parse->resultRelation</literal>,
or at execution time by using
<function>ExecRelationIsTargetRelation()</function>.
An alternative possibility is to perform late locking within the
<function>ExecForeignUpdate</function> or
<function>ExecForeignDelete</function>
callback, but no special support is provided for this.
So, there would be no need to consider about EvalPlanQual. Sorry for
the noise.
Best regards,
Etsuro Fujita
