Re: Async PQgetResult() question.

Matthew Hagerty <mhagerty(at)voyager(dot)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