In response to "Brendon Sablinski" <mapletide@xxxxxxxxx>:
> I have a need to do asynchronous query processing. I am a little confused
> by the order and frequency of calls. Can someone tell me if the below is
> correct? The code comments are littered with my questions.
>
> PQsendQueryParams(pgconn, "SELECT ..", ....);
>
> while(1)
> {
> epoll/poll/select PQsocket(pgconn) [read]
>
> // call this each time poll indicates data is ready?
> PQconsumeInput(pgconn);
What poll? PQconsumeInput()/PQisBusy() _is_ the poll.
Also, you should check the return code. If you get 0, something has gone wrong.
> // If isBusy returns 1, just poll again? Will this indicate 0 when I have
> a full PGResult set?
> // Or, can it split the results of a single statement across multiple
> result sets.
> if(PQisBusy())
> conitnue;
Is this just experimenting? Note that by simply staying within the loop,
you basically wrap asynchronous access with synchronous code. In your real
code, you should return to whatever else the program has to work on.
> // I know the docs say keep calling getResult until it returns NULL. In
> my
> // case, I am wondering if that is needed. I only send one statement at a
> // time to the server. The connection is not listening for notifies
> either. Do
> // I still need to call getResult multiple times? I saw many examples
> online
> // that DO NOT call it multiple times, all of them executed a single
> statement.
If you know for a fact that there are no more statements in processing, there's
no need to call PQgetResult() any more.
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.
> res = PQgetResult(pgconn);
>
> process_results(res);
> }
>
> thanks, brendon
>
--
Bill Moran
http://www.potentialtech.com
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
