From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jelte Fennema <postgres(at)jeltef(dot)nl> |
Cc: | Jeroen Vermeulen <jtvjtv(at)gmail(dot)com>, daniel(at)yesql(dot)se, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: libpq: PQgetCopyData() and allocation overhead |
Date: | 2023-03-03 16:33:29 |
Message-ID: | 2478499.1677861209@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jelte Fennema <postgres(at)jeltef(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-03-03 16:37:56 | Re: pgsql: Harden new test case against force_parallel_mode = regress. |
Previous Message | Drouvot, Bertrand | 2023-03-03 16:28:47 | Re: Fix comments in gistxlogDelete, xl_heap_freeze_page and xl_btree_delete |