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

From Etsuro Fujita
Subject Re: de-deduplicate code in DML execution hooks in postgres_fdw
Date
Msg-id 5C3EC833.9010508@lab.ntt.co.jp
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  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
(2019/01/07 20:26), Etsuro Fujita wrote:
> (2018/11/30 19:55), Etsuro Fujita wrote:
>> One thing we would need to discuss more about this is the name of a new
>> function added by the patch. IIRC, we have three options so far [1]:
>>
>> 1) perform_one_foreign_dml proposed by Ashutosh
>> 2) execute_dml_single_row proposed by Michael
>> 3) execute_parameterized_dml_stmt proposed by me
>>
>> I'll withdraw my proposal; I think #1 and #2 would describe the
>> functionality better than #3. My vote would go to #2 or
>> execute_dml_stmt_single_row, which moves the function much more closer
>> to execute_dml_stmt. I'd like to hear the opinions of others.
>
> 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.

Best regards,
Etsuro Fujita



pgsql-hackers by date:

Previous
From: Etsuro Fujita
Date:
Subject: Re: Query with high planning time at version 11.1 compared versions10.5 and 11.0
Next
From: Tatsuo Ishii
Date:
Subject: Re: Libpq support to connect to standby server as priority