Re: [patch] libpq one-row-at-a-time API

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Marko Kreen <markokr(at)gmail(dot)com>
Cc: Postgres Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [patch] libpq one-row-at-a-time API
Date: 2012-06-16 15:09:19
Message-ID: 19704.1339859359@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Marko Kreen <markokr(at)gmail(dot)com> writes:
>> 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.
>>
>> * 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.

I guess this raises the question of whether we ought to revert the
row-callback patch entirely and support only this approach. IMO
it is (barely) not too late to do that for 9.2, if we want to.
If we don't want to, then this is just another new feature and
should be considered for 9.3.

What I like about this is the greatly simpler and harder-to-misuse
API. The only arguable drawback is that there's still at least one
malloc/free cycle per tuple, imposed by the creation of a PGresult
for each one, whereas the callback approach avoids that. But worrying
about that could be considered to be vast overoptimization; the backend
has certainly spent a lot more overhead than that generating the tuple.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-06-16 15:15:30 Re: libpq compression
Previous Message Marko Kreen 2012-06-16 14:22:46 Re: [patch] libpq one-row-at-a-time API