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

In response to

• Async PQgetResult() question. at 2001-07-07 03:09:40 from Matthew Hagerty

Responses

• Re: Async PQgetResult() question. at 2001-07-07 17:40:57 from Matthew Hagerty

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