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.
> 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
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
In response to
pgsql-hackers by date
|Next:||From: Matthew Hagerty||Date: 2001-07-07 17:40:57|
|Subject: Re: Async PQgetResult() question. |
|Previous:||From: Lamar Owen||Date: 2001-07-07 14:36:29|
|Subject: Re: Pg on SMP half-powered|