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 по дате отправления: