Re: [patch] libpq one-row-at-a-time API
От | Marko Kreen |
---|---|
Тема | Re: [patch] libpq one-row-at-a-time API |
Дата | |
Msg-id | CACMqXCJUw4O3QN0tmunC=Dkd1aC6+ZJH3AyTypYqxXinLnmw9w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [patch] libpq one-row-at-a-time API (Merlin Moncure <mmoncure@gmail.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: