>>If you know for a fact that there are no more statements in processing, there's
>>no need to call PQgetResult() any more.
thanks, that is what I thought.
>>What poll? PQconsumeInput()/PQisBusy() _is_ the poll.
comsumeInput and isBusy is not a poll. A poll tells you if
data is ready. When data is ready you can then call recv() w/o
blocking your application. If you call consumeInput without verifying
data is ready, recv() would block (unless you set the pgconn.sockfd to
nonblocking mode).
>>Also, you should check the return code.
This is just an example of the flow and sequence of PQ calls.
>However, if you know for a fact that there could never be more than a single
>query in the pipeline, it's unlikely that your code is written to handle
>asynchronous processing.
Asynch
doesn't mean you have to have multiple outstanding requests on a
pgconn. All it means is that your application is not waiting for the
PGResult, it gets it later when the server is done. It has nothing to
do with how many results maybe pending. The application layer is
queuing queries requests because they need to be exectued at different
times from different clients. Batching doesn't work here.
thanks, brendon
