On Tue, Jul 24, 2012 at 11:08 AM, Marko Kreen <markokr@gmail.com> wrote:
>> I'm arguing that *all* data getting must continue to do so through the
>> result object, and bypassing the result to get at data is breaking the
>> result abstraction in the libpq api. I bet you can still maintain
>> data access through result object while avoiding extra copies.
>
> Well, the main problem this week is whether we should
> apply PQsetSingleRowMode() from single-row-mode1
> or from single-row-mode2 branch?
>
> The PQgetRowData() is unimportant as it just exposes
> the rowBuf to user and thats all.
right. branch 1 (containing PQgetRowData) seems wrong to me. so, if
given that choice, I'd argue for branch 2, forcing a PGresult pull on
each row. However, what you were gunning for via branch 1 which is
extra performance via removing the extra allocs is important and
useful; hopefully we can get the best of both worlds, or punt and
settle on branch 2.
>> For example, maybe PQsetSingleRowMode maybe should return a result object?
>
> What do you mean by that? And have you though about both
> sync and async usage patterns?
No, I haven't -- at least not very well. The basic idea is that
PQsetSingleRowMode turns into PQgetSingleRowResult() and returns a
result object. For row by row an extra API call gets called (maybe
PQgetNextRow(PGconn, PGresult)) that does the behind the scenes work
under the existing result object. This is the same general structure
you have in branch 2, but the result allocation is move out of the
loop. Presumably sync and async would then follow the same pattern,
but we'd still have to be able to guarantee non-blocking behavior in
the async api.
merlin