Re: libpq: PQgetCopyData() and allocation overhead

Jeroen Vermeulen <jtvjtv@gmail.com>

From: Jeroen Vermeulen <jtvjtv@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jelte Fennema <postgres@jeltef.nl>, daniel@yesql.se, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2023-03-03T19:30:37Z
Lists: pgsql-hackers

Attachments

Interested, yes.  But there may be reasons not to do that.  Last time I
looked the binary format wasn't documented.

Anyway, I tried re-implementing pqGetCopyData3() using the callback.
Wasn't hard, but I did have to add a way for the callback to return an
error.  Kept it pretty dumb for now, hoping a sensible rule will become
obvious later.

Saw no obvious performance impact, so that's good.


Jeroen

On Fri, 3 Mar 2023 at 19:53, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Jeroen Vermeulen <jtvjtv@gmail.com> writes:
> > The printf() is just the simplest example that sprang to mind though.
> > There may be other use-cases out there involving  libraries that require
> > zero-terminated strings, and I figured an ability to set a sentinel could
> > help those.
>
> Well, since it won't help for binary COPY, I'm skeptical that this is
> something we should cater to.  Anybody who's sufficiently worried about
> performance to be trying to remove malloc/free cycles ought to be
> interested in binary COPY as well.
>
>                         regards, tom lane
>