On Tue, Jul 24, 2012 at 11:34 PM, Merlin Moncure <mmonc...@gmail.com> wrote:
> On Tue, Jul 24, 2012 at 2:37 PM, Tom Lane <t...@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.


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to