On 2019/02/20 13:54, Tom Lane wrote:
> 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.
IIUC, in the new approach, only the root of the inheritance tree (target
table specified in the query) will appear in the query's join tree, not
the child target tables, so pushing updates with joins to the remote side
seems a bit hard, because we're not going to consider child joins. Maybe
I'm missing something though.
Thanks,
Amit
