Re: PQputCopyEnd doesn't adhere to its API contract
От | Robert Haas |
---|---|
Тема | Re: PQputCopyEnd doesn't adhere to its API contract |
Дата | |
Msg-id | CA+TgmoatCKdniH-UhMCrJxrdE2Ezh9Dt41pOkRqDHYHhEja0JA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: PQputCopyEnd doesn't adhere to its API contract (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: PQputCopyEnd doesn't adhere to its API contract
|
Список | pgsql-hackers |
On Thu, May 8, 2014 at 12:53 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> What I'm now thinking I need to do is something like this: > >> 1. If PQputCopyEnd returns -1, error. >> 2. while ((rc = PQflush(conn)) != 0) { if (rc < 0) { error; } else { >> wait for socket to become read-ready or write-ready; } } >> 3. while (PQisBusy(conn)) { wait for the socket to become read-ready; } >> 4. PQgetResult() > >> Does that sound right? > > Yeah, more or less --- I think you need a PQconsumeInput there somewhere. > > There is a PQflush call in PQconsumeInput that is intended to keep clients > from having to do that for themselves; but I'm not sure that it helps, > since clients probably only call PQconsumeInput when the socket is > read-ready --- and it wouldn't be in this situation. OK. It still seems to me that there's a doc fix needed here, if nothing else. The documentation for PQputCopyEnd() clearly implies that if you get a return value of 1, the message is sent, and that's just not true. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: