Re: Make COPY format extendable: Extract COPY TO format implementations - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: Make COPY format extendable: Extract COPY TO format implementations
Date
Msg-id CAKFQuwYuGe2Qb_Q6a61wSmNSmAe-ni5=WpRXqittYYki3EO_Tg@mail.gmail.com
Whole thread Raw
In response to Re: Make COPY format extendable: Extract COPY TO format implementations  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-hackers
On Mon, Mar 31, 2025 at 11:52 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
On Sat, Mar 29, 2025 at 9:49 AM David G. Johnston
<david.g.johnston@gmail.com> wrote:
>
> On Wed, Mar 26, 2025 at 8:28 PM Sutou Kouhei <kou@clear-code.com> wrote:
>>
>>
>> The attached v39 patch set uses the followings:
>>
>> 0001: Create copyto_internal.h and change COPY_XXX to
>>       COPY_SOURCE_XXX and COPY_DEST_XXX accordingly.
>>       (Same as 1. in your suggestion)
>> 0002: Support custom format for both COPY TO and COPY FROM.
>>       (Same as 2. in your suggestion)
>> 0003: Expose necessary helper functions such as CopySendEndOfRow()
>>       and add CopyFromSkipErrorRow().
>>       (3. + 4. in your suggestion)
>> 0004: Define handler functions for built-in formats.
>>       (Not included in your suggestion)
>> 0005: Documentation. (WIP)
>>       (Same as 5. in your suggestion)
>>
>
> I prefer keeping 0002 and 0004 separate.  In particular, keeping the design choice of "unqualified internal format names ignore search_path" should stand out as its own commit.

What is the point of having separate commits for already-agreed design
choices? I guess that it would make it easier to revert that decision.
But I think it makes more sense that if we agree with "unqualified
internal format names ignore search_path" the original commit includes
that decision and describes it in the commit message. If we want to
change that design based on the discussion later on, we can have a
separate commit that makes that change and has the link to the
discussion.

Fair.  Comment withdrawn.  Though I was referring to the WIP patches; I figured the final patch would squash this all together in any case.

David J.

pgsql-hackers by date:

Previous
From: Christoph Berg
Date:
Subject: Re: pgsql: Add memory/disk usage for Window aggregate nodes in EXPLAIN.
Next
From: Ilia Evdokimov
Date:
Subject: Re: explain analyze rows=%.0f