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
- pqhandlecopydata.diff (text/x-patch)
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 >