Vaishnavi Prabakaran wrote: > So, attached the alternative fix for this issue. > Please share me your thoughts.
I assume you prefer the alternative fix because it's simpler. > 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. +1 The main question is whether the predicates enforced by PQsetSingleRowMode() apply in batch mode in all cases when it's legit to call that function. Two predicates that may be problematic are: if (conn->asyncStatus != PGASYNC_BUSY) return 0; and if (conn->result) return 0; The general case with batch mode is that, from the doc: "The client interleaves result processing with sending batch queries" Note that I've not even tested that here, I've tested batching a bunch of queries in a first step and getting the results in a second step. I am not confident that the above predicates will be true in all cases. Also your alternative fix assumes that we add a user-visible exception to PQsetSingleRowMode in batch mode, whereby it must not be called as currently documented: "call PQsetSingleRowMode immediately after a successful call of PQsendQuery (or a sibling function)" My gut feeling is that it's not the right direction, I prefer making the single-row a per-query attribute internally and keep PQsetSingleRowMode's contract unchanged from the user's perspective. Best regards, -- Daniel Vérité PostgreSQL-powered mailer: http://www.manitou-mail.org Twitter: @DanielVerite -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers