Re: libpq and prepared statements progress for 8.0

From: Greg Stark <gsstark(at)mit(dot)edu>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: libpq and prepared statements progress for 8.0
Date: 2004-10-07 05:23:56
Message-ID: 87hdp7xfrn.fsf@stark.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches


Abhijit Menon-Sen <ams(at)oryx(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gavin Sherry 2004-10-07 05:27:05 Re: initdb crash
Previous Message David Garamond 2004-10-07 04:47:55 Re: database constraints

Browse pgsql-patches by date

  From Date Subject
Next Message Fabien COELHO 2004-10-07 06:38:16 Re: Two-phase commit
Previous Message Neil Conway 2004-10-07 05:15:44 Re: [psql] Setting the PROMPT on command line