Re: libpq: PQgetCopyData() and allocation overhead

Jeroen Vermeulen <jtvjtv(at)gmail(dot)com> writes:
> On Fri, 3 Mar 2023 at 17:33, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Let's not do that. Declare it const char *, or maybe better const void *.

> Personally I would much prefer "char" over "void" here:
> * It really is a char buffer, containing text.

Not in binary-mode COPY.

> As for const, I would definitely have preferred that. But if the caller
> needs a zero-terminated string, forcing them into a memcpy() would kind of
> defeat the purpose.

I'm willing to grant that avoiding malloc-and-free is worth the trouble.
I'm not willing to allow applications to scribble on libpq buffers to
avoid memcpy. Even your not-a-patch patch fails to make the case that
this is essential, because you could have used fwrite() instead of
printf() (which would be significantly faster yet btw, printf formatting
ain't cheap).

> Can do that, sure. I'll also try benchmarking a variant that doesn't take
> a callback at all, but gives you the buffer pointer in addition to the
> size/status return. I don't generally like callbacks.

Um ... that would require an assumption that libpq neither changes nor
moves that buffer before returning to the caller. I don't much like
that either.

regards, tom lane