Merlin Moncure <mmoncure@gmail.com> writes:
> Either way, it looks like there's plausible paths to optimizing
> repeated result fetch without having expose an alternate data-fetching
> API and that the proposed implementation doesn't appear to be a wall
> in terms of getting there. So I'm firmly in the non-exposed-rowbuf
> camp, even if we can't expose an optimal implementation in time for
> 9.2.
Yeah, the schedule argument is a strong one. If we put in PQgetRowData
now, we'll be stuck with it forevermore. It would be better to push
that part of the patch to 9.3 so we can have more time to think it over
and investigate alternatives. The single-row mode is already enough to
solve the demonstrated client-side performance issues we know about.
So IMO it would be a lot smarter to be spending our time right now on
making sure we have *that* part of the patch right.
In particular I agree that PQsetSingleRowMode is a bit ugly, so I'm
wondering about your thoughts on providing PQgetSingleRowResult instead.
I don't see how to make that work in async mode. I think the library
needs to be aware of whether it's supposed to return a single-row result
in advance of actually doing so --- for instance, how can PQisBusy
possibly give the correct answer if it doesn't know whether having
received the first row is sufficient? (Yeah, I know we could invent
a separate flavor of PQisBusy for single-row usage, but ick. There are
implementation problems too, such as possibly having already copied a
lot of rows into a work-in-progress PGresult.)
The thing I fundamentally don't like about PQsetSingleRowMode is that
there's such a narrow window of time to use it correctly -- as soon as
you've done even one PQconsumeInput, it's too late. (Or maybe not, if
the server is slow, which makes it timing-dependent whether you'll
observe a bug. Maybe we should add more internal state so that we can
consistently throw error if you've done any PQconsumeInput?) The most
obvious alternative is to invent new versions of the PQsendXXX functions
with an additional flag parameter; but there are enough of them to make
that not very attractive either.
regards, tom lane