Fujita-san, Thanks for the quick follow up.
On Wed, Aug 7, 2019 at 11:30 AM Etsuro Fujita <etsuro.fuj...@gmail.com> wrote: > On Wed, Aug 7, 2019 at 10:24 AM Amit Langote <amitlangot...@gmail.com> wrote: > > * Regarding setting ForeignScan.resultRelIndex even for non-direct > > modifications, maybe that's not a good idea anymore. A foreign table > > result relation might be involved in a local join, which prevents it > > from being directly-modifiable and also hides the ForeignScan node > > from being easily modifiable in PlanForeignModify. Maybe, we should > > just interpret resultRelIndex as being set only when > > direct-modification is feasible. > > Yeah, I think so; when using PlanForeignModify because for example, > the foreign table result relation is involved in a local join, as you > mentioned, ForeignScan.operation would be left unchanged (ie, > CMD_SELECT), so to me it's more understandable to not set > ForeignScan.resultRelIndex. OK. > > Should we rename the field > > accordingly to be self-documenting? > > IMO I like the name resultRelIndex, but do you have any better idea? On second thought, I'm fine with sticking to resultRelIndex. Trying to make it self documenting might make the name very long. Here are the updated patches. Thanks, Amit
v5-0001-Revise-BeginDirectModify-API-to-pass-ResultRelInf.patch
Description: Binary data
v5-0003-Rearrange-partition-update-row-movement-code-a-bi.patch
Description: Binary data
v5-0004-Refactor-transition-tuple-capture-code-a-bit.patch
Description: Binary data
v5-0002-Remove-es_result_relation_info.patch
Description: Binary data
