Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> writes:
> On 2019/02/20 6:48, Tom Lane wrote:
>> What if we dropped that idea, and instead defined the plan tree as
>> returning only the columns that are updated by SET, plus the row
>> identity? It would then be the ModifyTable node's job to fetch the
>> original tuple using the row identity (which it must do anyway) and
>> form the new tuple by combining the updated columns from the plan
>> output with the non-updated columns from the original tuple.
> Regarding child target relations that are foreign tables, the
> expand-target-inheritance-at-the-bottom approach perhaps leaves no way to
> allow pushing the update (possibly with joins) to remote side?
That's something we'd need to think about. Obviously, anything
along this line breaks the existing FDW update APIs, but let's assume
that's acceptable. Is it impossible, or even hard, for an FDW to
support this definition of UPDATE rather than the existing one?
I don't think so --- it seems like it's just different --- but
I might well be missing something.
regards, tom lane
