Re: libpq: PQgetCopyData() and allocation overhead - Mailing list pgsql-hackers

From Tom Lane
Subject Re: libpq: PQgetCopyData() and allocation overhead
Date
Msg-id 2478499.1677861209@sss.pgh.pa.us
Whole thread Raw
In response to Re: libpq: PQgetCopyData() and allocation overhead  (Jelte Fennema <postgres@jeltef.nl>)
Responses Re: libpq: PQgetCopyData() and allocation overhead  (Jeroen Vermeulen <jtvjtv@gmail.com>)
Re: libpq: PQgetCopyData() and allocation overhead  (Jelte Fennema <postgres@jeltef.nl>)
List pgsql-hackers
Jelte Fennema <postgres@jeltef.nl> writes:
> Did you try with PQExpBuffer? I still think that probably fits better
> in the API design of libpq.

If you mean exposing PQExpBuffer to users of libpq-fe.h, I'd be very
seriously against that.  I realize that libpq exposes it at an ABI
level, but that doesn't mean we want non-Postgres code to use it.
I also don't see what it'd add for this particular use-case.

One thing I don't care for at all in the proposed API spec is the bit
about how the handler function can scribble on the passed buffer.
Let's not do that.  Declare it const char *, or maybe better const void *.

Rather than duplicating most of pqGetCopyData3, I'd suggest revising
it to take a callback, where the callback is either user-supplied
or is supplied by PQgetCopyData to emulate the existing behavior.
This would both avoid duplicate coding and provide a simple check that
you've made a usable callback API (in particular, one that can do
something sane for error cases).

            regards, tom lane



pgsql-hackers by date:

Previous
From: "Drouvot, Bertrand"
Date:
Subject: Re: Fix comments in gistxlogDelete, xl_heap_freeze_page and xl_btree_delete
Next
From: Tom Lane
Date:
Subject: Re: pgsql: Harden new test case against force_parallel_mode = regress.