Re: libpq: PQgetCopyData() and allocation overhead

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: libpq: PQgetCopyData() and allocation overhead
Дата
Msg-id 2488737.1677863665@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: libpq: PQgetCopyData() and allocation overhead  (Jeroen Vermeulen <jtvjtv@gmail.com>)
Ответы Re: libpq: PQgetCopyData() and allocation overhead  (Jeroen Vermeulen <jtvjtv@gmail.com>)
Список pgsql-hackers
Jeroen Vermeulen <jtvjtv@gmail.com> writes:
> On Fri, 3 Mar 2023 at 17:33, Tom Lane <tgl@sss.pgh.pa.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: libpq-fe.h should compile *entirely* standalone
Следующее
От: Robert Haas
Дата:
Сообщение: Re: pgsql: Harden new test case against force_parallel_mode = regress.