Re: Odd behavior in foreign table modification (Was: Re: Optimization for updating foreign tables in Postgres FDW)

From: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Thom Brown <thom(at)linux(dot)com>, Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Odd behavior in foreign table modification (Was: Re: Optimization for updating foreign tables in Postgres FDW)
Date: 2016-01-28 12:36:58
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 2016/01/28 12:58, Robert Haas wrote:
> On Thu, Jan 21, 2016 at 4:05 AM, Etsuro Fujita
> <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>>> By the way, I'm not too sure I understand the need for the core
>>> changes that are part of this patch, and I think that point merits
>>> some discussion. Whenever you change core like this, you're changing
>>> the contract between the FDW and core; it's not just postgres_fdw that
>>> needs updating, but every FDW. So we'd better be pretty sure we need
>>> these changes and they are adequately justified before we think about
>>> putting them into the tree. Are these core changes really needed
>>> here, or can we fix this whole issue in postgres_fdw and leave the
>>> core code alone?

>> Well, if we think it is the FDW's responsibility to insert a valid value for
>> tableoid in the returned slot during ExecForeignInsert, ExecForeignUpdate or
>> ExecForeignDelete, we don't need those core changes. However, I think it
>> would be better that that's done by ModifyTable in the same way as
>> ForeignScan does in ForeignNext, IMO. That eliminates the need for
>> postgres_fdw or any other FDW to do that business in the callback routines.

> I'm not necessarily opposed to the core changes, but I want to
> understand better what complexity they are avoiding. Can you send a
> version of this patch that only touches postgres_fdw, so I can
> compare?

Attached is that version of the patch.

I think that postgres_fdw might be able to insert a tableoid value in
the returned slot in e.g., postgresExecForeignInsert if AFTER ROW
Triggers or RETURNING expressions reference that value, but I didn't do
anything about that.

Best regards,
Etsuro Fujita

Attachment Content-Type Size
fdw-foreign-modify-rmh-efujita.patch application/x-patch 9.5 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2016-01-28 12:39:13 Comment typos in source code: s/thats/that is/
Previous Message Fujii Masao 2016-01-28 12:32:11 Several problems in tab-completions for SET/RESET