Re: Make COPY format extendable: Extract COPY TO format implementations

Hi,

In
<OS3PR01MB9882F023300EDC5AFD8A8339F58EA(at)OS3PR01MB9882(dot)jpnprd01(dot)prod(dot)outlook(dot)com>
"RE: Make COPY format extendable: Extract COPY TO format implementations" on Tue, 12 Dec 2023 02:31:53 +0000,
"Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com> wrote:

>> Can we discuss how to proceed this improvement?
>>
>> There are 2 approaches for it:
>>
>> 1. Do the followings concurrently:
>> a. Implementing small changes that got a consensus and
>> merge them step-by-step
>> (e.g. We got a consensus that we need to extract the
>> current format related routines.)
>> b. Discuss design
>>
>> (v1-v3 patches use this approach.)
>>
>> 2. Implement one (large) complete patch set with design
>> discussion and merge it
>>
>> (v4- patches use this approach.)
>>
>> Which approach is preferred? (Or should we choose another
>> approach?)
>>
>> I thought that 1. is preferred because it will reduce review
>> cost. So I chose 1.
>
> I'm ok to use approach 1, but could you please divide a large patch? E.g.,
>
> 0001. defines an infrastructure for copy-API
> 0002. adjusts current codes to use APIs
> 0003. adds a test module in src/test/modules or contrib.
> ...
>
> This approach helps reviewers to see patches deeper. Separated patches can be
> combined when they are close to committable.

It seems that I should have chosen another approach based on
comments so far:

3. Do the followings in order:
a. Implement a workable (but maybe dirty and/or incomplete)
implementation to discuss design like [1], discuss
design with it and get a consensus on design
b. Implement small patches based on the design

[1]: https://www.postgresql.org/message-id/CAD21AoCunywHird3GaPzWe6s9JG1wzxj3Cr6vGN36DDheGjOjA%40mail.gmail.com

I'll implement a custom COPY FORMAT handler with [1] and
provide a feedback with the experience. (It's for a.)

Thanks,
--
kou