>>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.
