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 | a31f779e-9cb8-1ea5-71a6-bca6adbfa6a4@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: [HACKERS] Bug in ExecModifyTable function and trigger issues forforeign tables (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>) |
Ответы |
Re: [HACKERS] Bug in ExecModifyTable function and trigger issuesfor foreign tables
|
Список | pgsql-hackers |
On 2017/06/02 18:10, Etsuro Fujita wrote: > On 2017/05/16 21:36, Etsuro Fujita wrote: >> One approach I came up with to fix this issue is to rewrite the >> targetList entries of an inherited UPDATE/DELETE properly using >> rewriteTargetListUD, when generating a plan for each child table in >> inheritance_planner. Attached is a WIP patch for that. Maybe I am >> missing something, though. > > While updating the patch, I noticed the patch rewrites the UPDATE > targetList incorrectly in some cases; rewrite_inherited_tlist I added to > adjust_appendrel_attrs (1) removes all junk items from the targetList > and (2) adds junk items for the child table using rewriteTargetListUD, > but it's wrong to drop all junk items in cases where there are junk > items for some other reasons than rewriteTargetListUD. Consider junk > items containing MULTIEXPR SubLink. One way I came up with to fix this > is to change (1) to only remove junk items with resname; since junk > items added by rewriteTargetListUD should have resname (note: we would > need resname to call ExecFindJunkAttributeInTlist at execution time!) > while other junk items wouldn't have resname (see > transformUpdateTargetList), we could correctly replace junk items added > by rewriteTargetListUD for the parent with ones for the child, by that > change. I might be missing something, though. Comments welcome. I updated the patch that way. Please find attached an updated version. Other changes: * Moved the initialization for "tupleid" I added in ExecModifyTable as discussed before, which I think is essentially the same as proposed by Ildus in [1], since I think that would be more consistent with "oldtuple". * Added regression tests. Anyway I'll add this to the next commitfest. Best regards, Etsuro Fujita [1] https://www.postgresql.org/message-id/20170514150525.0346ba72%40postgrespro.ru -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Вложения
В списке pgsql-hackers по дате отправления: