Re: libpq and prepared statements progress for 8.0
От | Greg Stark |
---|---|
Тема | Re: libpq and prepared statements progress for 8.0 |
Дата | |
Msg-id | 87hdp7xfrn.fsf@stark.xeocode.com обсуждение исходный текст |
Ответ на | Re: libpq and prepared statements progress for 8.0 (Abhijit Menon-Sen <ams@oryx.com>) |
Ответы |
Re: libpq and prepared statements progress for 8.0
|
Список | pgsql-hackers |
Abhijit Menon-Sen <ams@oryx.com> writes: > --- fe-protocol3.c.1~ 2004-10-05 18:59:55.293092244 +0530 > +++ fe-protocol3.c 2004-10-05 19:17:48.154807848 +0530 > @@ -220,6 +220,11 @@ pqParseInput3(PGconn *conn) > conn->asyncStatus = PGASYNC_READY; > break; > case '1': /* Parse Complete */ > + if (conn->result == NULL) > + conn->result = PQmakeEmptyPGresult(conn, > + PGRES_COMMAND_OK); > + conn->asyncStatus = PGASYNC_READY; > + break; > case '2': /* Bind Complete */ > case '3': /* Close Complete */ > /* Nothing to do for these message types */ So why is this part of the patch ok? Isn't it going to make libpq get confused every time a PQExecPrepared sends a v3.0 prepare message? It will mark the connection as PGASYNC_READY as soon as the prepare response is parsed instead of waiting for the responses from the bind and execute messages that have already been sent. This is more or less where I got stuck on my attempt at the same thing. It seems like to handle "bundled" calls like PQExecPrepared libpq would have to keep track of from what call various messages arose. That seems like it would complicate things quite a bit. -- greg
В списке pgsql-hackers по дате отправления: