Matthew Hagerty <mhagerty@voyager.net> writes:
> I'm working with pqlib in asynchronous mode and I have a question about
> PQgetResult. I have this situation:
> submit a query via PQsendQuery()
> flush to the backend with PQflush()
I think the flush is not necessary; PQsendQuery should do it.
> set my read descriptor on the socket and enter a select()
> select returns read_ready on the socket, so call PGconsumeInput()
> PQisBusy() returns zero, so call PQgetResult()
> PQgetResult() returns a pointer so do whatever with the result
> call PQclear() on the result
So far so good.
> Now what do I do?
Loop back to the PQisBusy() step. In practice, you are probably doing
this in an event-driven application, and the select() is the place in
the outer loop that blocks for an event. PQconsumeInput followed by
a PQisBusy/PQgetResult/process result loop are just your response
subroutine for an input-ready-on-the-database-connection event.
> The docs say that in async mode that PQgetResult() must
> be called until it returns NULL. But, how do I know that calling
> PQgetResult() a second, third, fourth, etc. time will not block?
When PQisBusy says you can.
> When
> PQisBusy() returns zero, does that mean that PQgetResult() is guaranteed
> not to block for all results, i.e. until it returns NULL and a new query is
> issued?
No, it means *one* result is available (or that a NULL is available, ie,
libpq has detected the end of the query cycle). Its answer will
probably change after you read the result.
regards, tom lane