Re: [HACKERS] Bug in ExecModifyTable function and trigger issues forforeign tables
От | Etsuro Fujita |
---|---|
Тема | Re: [HACKERS] Bug in ExecModifyTable function and trigger issues forforeign tables |
Дата | |
Msg-id | 428f1672-df54-de01-91da-b57365193bf4@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: [HACKERS] Bug in ExecModifyTable function and trigger issues forforeign tables (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>) |
Ответы |
Re: [HACKERS] Bug in ExecModifyTable function and trigger issues forforeign tables
|
Список | pgsql-hackers |
On 2017/06/16 19:26, Ashutosh Bapat wrote: > On Fri, Jun 16, 2017 at 3:35 PM, Etsuro Fujita >> Ashutosh mentioned his concern about what I proposed above before [2], but >> I'm not sure we should address that. And there have been no opinions from >> him (or anyone else) since then. So, I'd like to leave that for committer >> (ie, +1 for Ready for Committer). > > That issue has not been addressed. The reason stated was that it would > make code complicated. But I have not had chance to look at how > complicated would be and assess myself whether that's worth the > trouble. I have to admit that what I proposed upthread is a quick-and-dirty kluge. One thing I thought to address your concern was to move rewriteTargetListUD entirely from the rewriter to the planner when doing inherited UPDATE/DELETE, but I'm not sure that's a good idea, because at least I think that would need a lot more changes to the rewriter. Best regards, Etsuro Fujita
В списке pgsql-hackers по дате отправления: