I mean the next iteration of the above while statement. Referring to the doc, that would be the "next batch entry":
" To get the result of the first batch entry the client must call PQbatchQueueProcess. It must then call PQgetResult and handle the results until PQgetResult returns null (or would return null if called). The result from the next batch entry may then be retrieved using PQbatchQueueProcess and the cycle repeated"
Attached is a bare-bones testcase showing the problem. As it is, it works, retrieving results for three "SELECT 1" in the same batch. Now in order to use the single-row fetch mode, consider adding this: r = PQsetSingleRowMode(conn); if (r!=1) { fprintf(stderr, "PQsetSingleRowMode() failed for i=%d\n", i); }
When inserted after the call to PQbatchQueueProcess, which is what I understand you're saying works for you, it fails for me when starting to get the results of the 2nd query and after.
Thanks for explaining the issue in detail and yes, I do see the issue using your attached test file.
And I think the problem is with the "parseInput" call at the end of PQbatchQueueProcess().
I don't see the need for "parseInput" to cover the scope of PQbatchQueueProcess(), also anyways we do it in PQgetResult().
This function call changes the asyncstatus of connection to READY(following command complete message from backend), so eventually PQsetSingleRowMode() is failing. So, attached the alternative fix for this issue.
Please share me your thoughts.
I would also like to hear Craig's opinion on it before applying this fix to the original patch, just to make sure am not missing anything here.
