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

On Mon, Mar 31, 2025 at 11:52 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
wrote:

> On Sat, Mar 29, 2025 at 9:49 AM David G. Johnston
> <david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> >
> > On Wed, Mar 26, 2025 at 8:28 PM Sutou Kouhei <kou(at)clear-code(dot)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.