Marko Kreen <> 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

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

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to