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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Junwang Zhao <zhjwpku(at)gmail(dot)com>
Cc: Sutou Kouhei <kou(at)clear-code(dot)com>, sawada(dot)mshk(at)gmail(dot)com, michael(at)paquier(dot)xyz, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Make COPY format extendable: Extract COPY TO format implementations
Date: 2025-03-02 16:27:20
Message-ID: 3191030.1740932840@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Junwang Zhao <zhjwpku(at)gmail(dot)com> writes:
> While review another thread (Emitting JSON to file using COPY TO),
> I found the recently committed patches on this thread pass the
> CopyFormatOptions struct directly rather a pointer of the struct
> as a function parameter of CopyToGetRoutine and CopyFromGetRoutine.

Coverity is unhappy about that too:

/srv/coverity/git/pgsql-git/postgresql/src/backend/commands/copyto.c: 177 in CopyToGetRoutine()
171 .CopyToOneRow = CopyToBinaryOneRow,
172 .CopyToEnd = CopyToBinaryEnd,
173 };
174
175 /* Return a COPY TO routine for the given options */
176 static const CopyToRoutine *
>>> CID 1643911: Performance inefficiencies (PASS_BY_VALUE)
>>> Passing parameter opts of type "CopyFormatOptions" (size 184 bytes) by value, which exceeds the low threshold of 128 bytes.
177 CopyToGetRoutine(CopyFormatOptions opts)
178 {
179 if (opts.csv_mode)
180 return &CopyToRoutineCSV;

(and likewise for CopyFromGetRoutine). I realize that these
functions aren't called often enough for performance to be an
overriding concern, but it still seems like poor style.

> Then I took a quick look at the newly rebased patch set and
> found Sutou has already fixed this issue.

+1, except I'd suggest declaring the parameters as
"const CopyFormatOptions *opts".

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2025-03-02 17:21:39 Re: 64 bit numbers vs format strings
Previous Message Yura Sokolov 2025-03-02 15:20:07 Re: Allow table AMs to define their own reloptions