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. -- marko -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
