Re: Another way to fix inherited UPDATE/DELETE

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Another way to fix inherited UPDATE/DELETE
Date: 2019-02-20 15:06:56
Message-ID: 11876.1550675216@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> writes:
> On 2019/02/20 13:54, Tom Lane wrote:
>> 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.

Hm. Even if that's true (I'm not convinced), I don't think it's such a
significant use-case as to be considered a blocker.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-02-20 15:14:56 Re: Another way to fix inherited UPDATE/DELETE
Previous Message Nikita Glukhov 2019-02-20 14:46:47 Re: [PATCH] kNN for btree