Demos:
https://github.com/markokr/libpq-rowproc-demos/blob/master/demo-onerow-sync.c
https://github.com/markokr/libpq-rowproc-demos/blob/master/demo-onerow-async.c
Few clarifications below.
On Fri, Jun 15, 2012 at 9:21 PM, Marko Kreen <markokr@gmail.com> wrote:
> Now, looking at the problem with some perspective, the solution
> is obvious: when in single-row mode, the PQgetResult() must return
> proper PGresult for that single row. And everything else follows that.
>
> Such API is implemented in attached patch:
>
> * PQsetSingleRowMode(conn): set's single-row mode.
The function can be called only after PQsend* and before any
rows have arrived. This guarantees there will be no surprises
to PQexec* users who expect full resultset at once. Also it
guarantees that user will process resultset with PQgetResult()
loop, either sync or async. Next PQexec/PQsend call will
reset the flag. So it is active only for duration of processing
results from one command.
Currently it returns FALSE if called in wrong place and does
nothing. Only question I see here is whether it should set
error state on connection or not. It does not seem to be
improvement.
> * PQgetRowData(): can be called instead PQgetResult() to get raw row data
> in buffer, for more efficient processing. This is optional feature
> that provides the original row-callback promise of avoiding unnecessary
> row data copy.
>
> * Although PQgetRowData() makes callback API unnecessary, it is still
> fully compatible with it - the callback should not see any difference
> whether the resultset is processed in single-row mode or
> old single-PGresult mode. Unless it wants to - it can check
> PGRES_TUPLES_OK vs. PGRES_SINGLE_TUPLE.
The PQgetResult() is compatible with callbacks, the PQgetRowData()
bypasses them.
--
marko