On Tue, Jul 24, 2012 at 11:34 PM, Merlin Moncure <mmoncure@gmail.com> wrote:
> On Tue, Jul 24, 2012 at 2:37 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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?
>
> Well (Marko probably wants to slap me with a halibut by now), the
> original intent was for it not to have to: PQgetSingleRowResult is
> more 'construct result for single row iteration', so it would never
> block -- it only sets the internal single row mode and instantiates
> the result object. After that, you can do do standard
> consumeinput/isbusy processing on the conn. The actual iteration
> routine would be like PQiterateResult which you could guard with
> PQisBusy. Like I said: it's the same general structure but the result
> construction is moved out of the loop.
If you really don't like PQsetSingleRowMode, then I would prefer
new PQsend* functions to new fetch functions.
Because while send is one-shot affair, receive is complex state-machine
with requires multiple function calls.
--
marko