Re: de-deduplicate code in DML execution hooks in postgres_fdw - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: de-deduplicate code in DML execution hooks in postgres_fdw
Date
Msg-id 20190116065454.GA2550@paquier.xyz
Whole thread Raw
In response to Re: de-deduplicate code in DML execution hooks in postgres_fdw  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
Responses Re: de-deduplicate code in DML execution hooks in postgres_fdw  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
List pgsql-hackers
On Wed, Jan 16, 2019 at 02:59:15PM +0900, Etsuro Fujita wrote:
> (2019/01/07 20:26), Etsuro Fujita wrote:
>> On second thought I'd like to propose another option:
>> execute_foreign_modify because I think this would match the existing
>> helper functions for updating foreign tables in postgres_fdw.c better,
>> such as create_foreign_modify, prepare_foreign_modify and
>> finish_foreign_modify. I don't really think the function name should
>> contain "one" or "single_row". Like the names of the calling APIs (ie,
>> ExecForeignInsert, ExecForeignUpdate and ExecForeignDelete), I think
>> it's OK to omit such words from the function name. Here is an updated
>> version of the patch. In addition to the naming, I tweaked the function
>> a little bit to match other functions (mainly variable names), moved it
>> to the place where the helper functions are defined, fiddled with some
>> comments, and removed an extra include file that the original patch added.
>
> If there are no objections, I'll commit that version of the patch.

I think that you could use PgFdwModifyState for the second argument of
execute_foreign_modify instead of ResultRelInfo.  Except of that nit,
it looks fine to me, thanks for taking care of it.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: "Tsunakawa, Takayuki"
Date:
Subject: RE: Protect syscache from bloating with negative cache entries
Next
From: Amit Langote
Date:
Subject: Re: using expression syntax for partition bounds