Horton

Re: [HACKERS] Bug in ExecModifyTable function and trigger issues for foreign tables

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Dean Rasheed <dean.a.rasheed@gmail.com>
Cc: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>, Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>, Ildus Kurbangaliev <i.kurbangaliev@postgrespro.ru>, Dilip Kumar <dilipbalaut@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Robert Haas <robertmhaas@gmail.com>
Date: 2017-11-27T22:58:23Z
Lists: pgsql-hackers 
Dean Rasheed <dean.a.rasheed@gmail.com> writes:
> On 27 November 2017 at 16:35, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> On looking closer, the reason it's like that in Fujita-san's patch
>> is to minimize the API churn seen by FDW AddForeignUpdateTargets
>> functions, specifically whether they see a tlist that's before or
>> after what expand_targetlist() does.  I'm doubtful that the
>> potential savings is worth taking risks there.  In particular,
>> it seems like a good thing that expand_targetlist() verifies the
>> correct tlist ordering *after* the FDW function has acted.
>> So now my inclination is to leave this alone.

> Ah yes, that seems like a worthwhile check to keep. Never mind then.

Pushed with that and some cosmetic fiddling with comments and docs.
Thanks for the discussion!

			regards, tom lane

Commits

  1. Fix creation of resjunk tlist entries for inherited mixed UPDATE/DELETE.