On Tue, Jul 24, 2012 at 3:52 PM, Marko Kreen <markokr@gmail.com> wrote:
> * Is there better API than PQsetSingleRowMode()? New PQsend*
> functions is my alternative.
I would prefer to have PQsetSingleRowMode() over new flavor of PQsend.
To consolidate my argument above: since you're throwing PQgetResult in
the main iteration loop you're potentially walling yourself off from
one important optimization: not copying the result at all and reusing
the old one; that's going to produce the fastest possible code since
you're recovering all the attribute structures that have already been
set up unless you're willing to do the following:
Reading your original patch, what if at the line inside PQgetResult:
res = pqSingleRowResult(conn);
you instead manipulated the result the connection already had and
directly returned it -- discarding the result data but not the
attributes etc? Actually, you could even keep your API 'as is' if
you're willing to adjust the behavior of PQclear while the connection
is doing row by row results processing to be a no-op unless done.
Single row results' data would then be volatile across iterations,
not const -- even if you save off the pointer the connection can and
will rewrite the data portion of the PGresult. Any pointers to
PQgetdata'd values would have to be copied off between iterations
naturally (or the user can copy off using the user-facing copy result
function). This would be extremely efficient since we'd only even
need to extend PGresult buffer if a particular row was longer than the
longest one already fetched.
If all that's a bridge too far, we can look at re-jiggering the API
like I was thinking ealier to make the adjusted result scoping more
user visible or run your non-rowbuf-exposing patch as-is and hope for
optimizations down the line.
merlin