Re: Another way to fix inherited UPDATE/DELETE
| От | Tom Lane |
|---|---|
| Тема | Re: Another way to fix inherited UPDATE/DELETE |
| Дата | |
| Msg-id | 11876.1550675216@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: Another way to fix inherited UPDATE/DELETE (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
| Список | pgsql-hackers |
Amit Langote <Langote_Amit_f8@lab.ntt.co.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
В списке pgsql-hackers по дате отправления: