On Tue, Jul 24, 2012 at 4:59 PM, Marko Kreen <markokr@gmail.com> wrote:
> So if we give only PQgetResult() in 9.2, I do not see that we
> are locked out from any interesting optimizations.
Well, you are locked out of having PQgetResult reuse the conn's result
since that would then introduce potentially breaking changes to user
code. Here are the approaches I see:
1) introduce rowbuf (but not user exposed rowbuf) patch:
Not the fastest method. Users would begin using the feature and API
behaviors would be locked in -- only possible optmiization route would
be to try and make PQcopyResult as fast as possible.
2) expose PQgetRowData
Very fast, but foreign and somewhat awkward. Existing libpq wrappers
(libpqtypes, libpqxx etc) could not be converted to use without
extensive revision, if at all, and would be stuck with the slower
version of iteration. Also a side benefit here is that optimizing
result copying later has usefulness outside of row by row processing.
3) as #1, but instead of copying result, overwrite the data area.
this is bending the rule 'user defined lifetime of result' since each
iteration clears the data area of the PGresult. This is almost as fast
as #2, and existing libpq wrappers would be trivially converted to the
API.
4) as #3, but introduce a new iteration function
(PQiterateResult(conn, result)) that would be called instead of a
paired PQgetResult/PQclear. This would also be fast, and could almost
lay directly on top of #2 as an alternate optimization strategy -- the
set result mode would have to be modified (or and additional function
introduced) to return a result.
I feel like you're partial to #2 and appreciate that, but I'm really
quite skeptical about it as noted. #3 and #4 are not as well thought
out as what you've put together and would need some extra work and
buy-in to get out the door, so #2 seems like the lowest common
denominator (it would permanently preclude #3 and would require #4 to
introduce two new functions instead of just one). #1 of course would
bolt on to #2.
merlin