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 CAKFQuwaCHhrS+RE4p_OO6d7WEskd9b86-2cYcvChNkrP+7PJ7A@mail.gmail.com
Whole thread Raw
In response to Re: Make COPY format extendable: Extract COPY TO format implementations  (Sutou Kouhei <kou@clear-code.com>)
List pgsql-hackers
On Sat, Mar 29, 2025 at 1:57 AM Sutou Kouhei <kou@clear-code.com> wrote:
 
* I still think that someone may don't like defining COPY
  handlers for built-in formats. If we don't define COPY
  handlers for built-in formats finally, we can just drop
  0004.

We should (and usually do) dog-food APIs when reasonable and this situation seems quite reasonable.  I'd push back quite a bit about publishing this without any internal code leveraging it.


>> We can merge 0001 quickly, right?
>
> I don't think it makes sense to push only 0001 as it's a completely
> preliminary patch for subsequent patches. It would be prudent to push
> it once other patches are ready too.

Hmm. I feel that 0001 is a refactoring category patch like
merged patches. In general, distinct enum value names are
easier to understand.


I'm for pushing 0001.  We've had copyfrom_internal.h for a while now and this seems like a simple refactor to make that area of the code cleaner via symmetry.

David J.

pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Why does wait_for_log() return current file size
Next
From: "David G. Johnston"
Date:
Subject: Re: in BeginCopyTo make materialized view using COPY TO instead of COPY (query).