Thread: Nearing final release?
I think we are getting closer to a final release. I haven't seen many
_major_ failures in a few weeks, and the open items list is shrinking. I
would like us to make a concentrated effort to address or fix all the
open items by November 1 and consider a final 8.0 release during November.
---------------------------------------------------------------------------
PostgreSQL 8.0 Open Items =========================
Current version at http://candle.pha.pa.us/cgi-bin/pgopenitems.
Changes
-------
* Win32o fix query cancel in psql (?)o fix shared memory on Win2k terminal servero fix MSVC build to export SSL
symbolsoSIG_DFL handlingo Handle "lost signals" on backend startup (eg. shutdown, config file changes, etc)
* Tablespaceo fix ambiguity for objects using default tablespaceso fix case where template db already uses target
tablespaceofix error message when creating objects in schema that has a dropped tablespace as its defaulto remove
non-portableTABLESPACE clause from CREATE TABLE using a SET or ALTER command
* allow libpq to check parameterized data types
* adjust bgwriter defaults, allow disabling
* synchonize supported encodings and docs
Completed Since Previoius Beta
------------------------------
* cleanup FRONTEND use in /port, malloc, elog
* update encoding list to include win1250
* make pgxs install by default
* Win32o disable readline-required psql optionso fix SSL compileso add binary version stampso fix signal-safe socket
handlerfor SSLo start pg_autovacuum easilyo remove log timezone string from log_line_prefix '%t'o fix MinGW libpq to
exportonly required symbols
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
We see that the win32 version of PostgreSQL sometime does not respond to pgbench -S running on Linux. Try something like: pgbench -h windows_host -S -c 128 -t 1000 your_database on Linux/FreeBSD/UNIX or whatever. -- Tatsuo Ishii > I think we are getting closer to a final release. I haven't seen many > _major_ failures in a few weeks, and the open items list is shrinking. I > would like us to make a concentrated effort to address or fix all the > open items by November 1 and consider a final 8.0 release during November. > > --------------------------------------------------------------------------- > > > PostgreSQL 8.0 Open Items > ========================= > > Current version at http://candle.pha.pa.us/cgi-bin/pgopenitems. > > Changes > ------- > * Win32 > o fix query cancel in psql (?) > o fix shared memory on Win2k terminal server > o fix MSVC build to export SSL symbols > o SIG_DFL handling > o Handle "lost signals" on backend startup (eg. shutdown, > config file changes, etc) > * Tablespace > o fix ambiguity for objects using default tablespaces > o fix case where template db already uses target tablespace > o fix error message when creating objects in schema that has a > dropped tablespace as its default > o remove non-portable TABLESPACE clause from CREATE TABLE using > a SET or ALTER command > * allow libpq to check parameterized data types > * adjust bgwriter defaults, allow disabling > * synchonize supported encodings and docs > Completed Since Previoius Beta > ------------------------------ > * cleanup FRONTEND use in /port, malloc, elog > * update encoding list to include win1250 > * make pgxs install by default > * Win32 > o disable readline-required psql options > o fix SSL compiles > o add binary version stamps > o fix signal-safe socket handler for SSL > o start pg_autovacuum easily > o remove log timezone string from log_line_prefix '%t' > o fix MinGW libpq to export only required symbols > > > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 359-1001 > + If your life is a hard drive, | 13 Roberts Road > + Christ can be your backup. | Newtown Square, Pennsylvania 19073 > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly >
> -----Original Message----- > From: pgsql-hackers-owner@postgresql.org > [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Bruce Momjian > Sent: 16 October 2004 04:39 > To: PostgreSQL-development > Subject: [HACKERS] Nearing final release? > > > o fix MSVC build to export SSL symbols That should be OK now that you've applied Magnus' libpq patch that standardises the libpq exports and adds a dummy PQgetssl() to non-SSL builds. Regards, Dave
Bruce Momjian <pgman@candle.pha.pa.us> writes: > I think we are getting closer to a final release. >... > * synchonize supported encodings and docs Is this Abhijit's patch to add PQprepare() and PQsendPrepare()? http://archives.postgresql.org/pgsql-hackers/2004-10/msg00142.php I'm anxious to see this get in 8.0 so that the prepared query support can be used by DBD::pg and other libpq-based applications and drivers. I'm not sure whether the patch he sent is adequate, I looked at it myself and was a bit skeptical. But he said my concerns were misplaced. If somebody more authoritative could look at it I expect he would be happy to take any feedback into account and keep working on it. But if nobody says anything then I'm sure nothing's going to happen and the binary prepared queries will be useless for DBD::Pg and other libpq-based drivers. -- greg
Greg Stark <gsstark@mit.edu> writes:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> * synchonize supported encodings and docs
> Is this Abhijit's patch to add PQprepare() and PQsendPrepare()?
No ... does it look like it?
> I'm not sure whether the patch he sent is adequate, I looked at it
> myself and was a bit skeptical. But he said my concerns were
> misplaced.
[ looks... ] The patch is definitely broken as-is, because it changes
the application-visible behavior of existing functions --- in particular
PQsendQueryParams() followed by PQgetResult() will now return a bogus
additional PGresult. I think the cleanest solution is probably to add a
state flag indicating whether ParseComplete should generate a PGresult
or not.
regards, tom lane
It seems most logical to me to break the fundamental operations into: 1. Prepare to create the compiled query plan 2. Describe to bind the query input/output parameters 3. Execute to produce a result set Or equivalent functionality. Then, you can bind all three parts into one operation if you want to, or you can execute the tasks separately. The notion of a flag to tell whether to return a result set or not has a smell of kludge to me. On the other hand, if getting something working in a hurry is the main purpose, then a flag might be the best way to go, and it could be more carefully refactored later. > -----Original Message----- > From: pgsql-hackers-owner@postgresql.org > [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Tom Lane > Sent: Saturday, October 16, 2004 3:41 PM > To: Greg Stark > Cc: pgsql-hackers@postgresql.org; Abhijit Menon-Sen > Subject: Re: [HACKERS] Nearing final release? > > > Greg Stark <gsstark@mit.edu> writes: > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > >> * synchonize supported encodings and docs > > > Is this Abhijit's patch to add PQprepare() and PQsendPrepare()? > > No ... does it look like it? > > > I'm not sure whether the patch he sent is adequate, I looked at it > > myself and was a bit skeptical. But he said my concerns were > > misplaced. > > [ looks... ] The patch is definitely broken as-is, because it > changes the application-visible behavior of existing > functions --- in particular > PQsendQueryParams() followed by PQgetResult() will now return > a bogus additional PGresult. I think the cleanest solution > is probably to add a state flag indicating whether > ParseComplete should generate a PGresult or not. > > regards, tom lane > > ---------------------------(end of > broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so > that your > message can get through to the mailing list cleanly >
> It seems most logical to me to break the fundamental operations into: > 1. Prepare to create the compiled query plan > 2. Describe to bind the query input/output parameters > 3. Execute to produce a result set > > Or equivalent functionality. Then, you can bind all three parts into > one operation if you want to, or you can execute the tasks separately. > > The notion of a flag to tell whether to return a result set or not has > a > smell of kludge to me. > > On the other hand, if getting something working in a hurry is the main > purpose, then a flag might be the best way to go, and it could be more > carefully refactored later. FWIW, is libpq going to have its version bumped? There's some interest in having this done from the FreeBSD camp because it make detecting installed verions of libpq much easier (7.4 client libs working with an 8.0 server?). In FreeBSD the server is split from the client programs and its libs. I'm sure other packagers may wish to see this happen too. *shrug* -sc -- Sean Chittenden
OK, open items updated. --------------------------------------------------------------------------- Dave Page wrote: > > > > -----Original Message----- > > From: pgsql-hackers-owner@postgresql.org > > [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Bruce Momjian > > Sent: 16 October 2004 04:39 > > To: PostgreSQL-development > > Subject: [HACKERS] Nearing final release? > > > > > > o fix MSVC build to export SSL symbols > > That should be OK now that you've applied Magnus' libpq patch that > standardises the libpq exports and adds a dummy PQgetssl() to non-SSL > builds. > > Regards, Dave > > ---------------------------(end of broadcast)--------------------------- > TIP 7: don't forget to increase your free space map settings > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Sean Chittenden wrote: > > It seems most logical to me to break the fundamental operations into: > > 1. Prepare to create the compiled query plan > > 2. Describe to bind the query input/output parameters > > 3. Execute to produce a result set > > > > Or equivalent functionality. Then, you can bind all three parts into > > one operation if you want to, or you can execute the tasks separately. > > > > The notion of a flag to tell whether to return a result set or not has > > a > > smell of kludge to me. > > > > On the other hand, if getting something working in a hurry is the main > > purpose, then a flag might be the best way to go, and it could be more > > carefully refactored later. > > FWIW, is libpq going to have its version bumped? There's some interest > in having this done from the FreeBSD camp because it make detecting > installed verions of libpq much easier (7.4 client libs working with an > 8.0 server?). In FreeBSD the server is split from the client programs > and its libs. I'm sure other packagers may wish to see this happen > too. *shrug* -sc We do a minor libpq version bump for every major PostgreSQL release. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Tom Lane <tgl@sss.pgh.pa.us> writes: > Greg Stark <gsstark@mit.edu> writes: > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > > * synchonize supported encodings and docs > > > Is this Abhijit's patch to add PQprepare() and PQsendPrepare()? > > No ... does it look like it? Er, oops. I quoted the wrong line. The line I meant to quote was: > > > * allow libpq to check parameterized data types Which is slightly more plausible. > > I'm not sure whether the patch he sent is adequate, I looked at it > > myself and was a bit skeptical. But he said my concerns were > > misplaced. > > [ looks... ] The patch is definitely broken as-is, because it changes > the application-visible behavior of existing functions --- in particular > PQsendQueryParams() followed by PQgetResult() will now return a bogus > additional PGresult. I think the cleanest solution is probably to add a > state flag indicating whether ParseComplete should generate a PGresult > or not. [That sounds exactly like what my concerns were.] Adding a flag is going to be enough for synchronous queries. But it seems like it has no chance of working for asynchronous queries. It would have to keep track of what all the pending requests are and the expected results. I think DBD::Pg would be pretty happy to have even synchronous queries working. Afaik that's all it uses currently. -- greg
Greg Stark <gsstark@mit.edu> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> I think the cleanest solution is probably to add a
>> state flag indicating whether ParseComplete should generate a PGresult
>> or not.
> Adding a flag is going to be enough for synchronous queries. But it
> seems like it has no chance of working for asynchronous queries. It
> would have to keep track of what all the pending requests are and the
> expected results.
Say what? Neither libpq nor the backend support multiple queries
in-flight at the same time.
regards, tom lane
At 2004-10-16 18:41:05 -0400, tgl@sss.pgh.pa.us wrote:
>
> I think the cleanest solution is probably to add a state flag indicating
> whether ParseComplete should generate a PGresult or not.
Like the appended (incremental) patch?
(I didn't think this would work, because I thought libpq would allow you
to send multiple queries before trying to read results. But you said it
didn't support that, so...)
-- ams
--- libpq-int.h.1~ 2004-10-18 17:42:13.175759981 +0530
+++ libpq-int.h 2004-10-18 17:43:40.105986570 +0530
@@ -269,6 +269,8 @@ * nonblock sending semantics */ bool ext_query; /*
wasour last query sent with extended * query protocol? */
+ bool sent_prepare; /* was our last Parse message sent with
+ * PQprepare? */ char copy_is_binary; /* 1 = copy binary, 0 = copy text */
int copy_already_done; /* # bytes already returned in * COPY
OUT*/
--- fe-exec.c.2~ 2004-10-18 17:47:55.540189274 +0530
+++ fe-exec.c 2004-10-18 17:48:30.119038902 +0530
@@ -686,6 +686,7 @@ goto sendFailed; conn->ext_query = true;
+ conn->sent_prepare = true; if (pqFlush(conn) < 0) goto sendFailed; conn->asyncStatus = PGASYNC_BUSY;
--- fe-protocol3.c.2~ 2004-10-18 17:44:06.616198123 +0530
+++ fe-protocol3.c 2004-10-18 17:46:34.431656569 +0530
@@ -220,10 +220,13 @@ conn->asyncStatus = PGASYNC_READY; break;
case'1': /* Parse Complete */
- if (conn->result == NULL)
- conn->result = PQmakeEmptyPGresult(conn,
- PGRES_COMMAND_OK);
- conn->asyncStatus = PGASYNC_READY;
+ if (conn->sent_prepare) {
+ if (!conn->result)
+ conn->result = PQmakeEmptyPGresult(conn,
+ PGRES_COMMAND_OK);
+ conn->asyncStatus = PGASYNC_READY;
+ conn->sent_prepare = false;
+ } break; case '2': /* Bind Complete */
case'3': /* Close Complete */
--- libpq-fe.h.2~ 2004-10-18 17:55:40.632064120 +0530
+++ libpq-fe.h 2004-10-18 17:56:26.501634328 +0530
@@ -312,9 +312,9 @@ int resultFormat);/* Interface for multiple-result or asynchronous queries */
-extern PGresult *PQsendPrepare(PGconn *conn, const char *stmtName,
- const char *query, int nParams,
- const Oid *paramTypes);
+extern int PQsendPrepare(PGconn *conn, const char *stmtName,
+ const char *query, int nParams,
+ const Oid *paramTypes);extern int PQsendQuery(PGconn *conn, const char *query);extern int
PQsendQueryParams(PGconn*conn, const char *command,
Here is a mega-patch that merges in your four previous patches. Is this
ready to be applied? Making libpq changes during beta is risky so we
had better be careful.
I have also attached your pgtest.c file.
---------------------------------------------------------------------------
Abhijit Menon-Sen wrote:
> At 2004-10-16 18:41:05 -0400, tgl@sss.pgh.pa.us wrote:
> >
> > I think the cleanest solution is probably to add a state flag indicating
> > whether ParseComplete should generate a PGresult or not.
>
> Like the appended (incremental) patch?
>
> (I didn't think this would work, because I thought libpq would allow you
> to send multiple queries before trying to read results. But you said it
> didn't support that, so...)
>
> -- ams
>
> --- libpq-int.h.1~ 2004-10-18 17:42:13.175759981 +0530
> +++ libpq-int.h 2004-10-18 17:43:40.105986570 +0530
> @@ -269,6 +269,8 @@
> * nonblock sending semantics */
> bool ext_query; /* was our last query sent with extended
> * query protocol? */
> + bool sent_prepare; /* was our last Parse message sent with
> + * PQprepare? */
> char copy_is_binary; /* 1 = copy binary, 0 = copy text */
> int copy_already_done; /* # bytes already returned in
> * COPY OUT */
>
> --- fe-exec.c.2~ 2004-10-18 17:47:55.540189274 +0530
> +++ fe-exec.c 2004-10-18 17:48:30.119038902 +0530
> @@ -686,6 +686,7 @@
> goto sendFailed;
>
> conn->ext_query = true;
> + conn->sent_prepare = true;
> if (pqFlush(conn) < 0)
> goto sendFailed;
> conn->asyncStatus = PGASYNC_BUSY;
>
> --- fe-protocol3.c.2~ 2004-10-18 17:44:06.616198123 +0530
> +++ fe-protocol3.c 2004-10-18 17:46:34.431656569 +0530
> @@ -220,10 +220,13 @@
> conn->asyncStatus = PGASYNC_READY;
> break;
> case '1': /* Parse Complete */
> - if (conn->result == NULL)
> - conn->result = PQmakeEmptyPGresult(conn,
> - PGRES_COMMAND_OK);
> - conn->asyncStatus = PGASYNC_READY;
> + if (conn->sent_prepare) {
> + if (!conn->result)
> + conn->result = PQmakeEmptyPGresult(conn,
> + PGRES_COMMAND_OK);
> + conn->asyncStatus = PGASYNC_READY;
> + conn->sent_prepare = false;
> + }
> break;
> case '2': /* Bind Complete */
> case '3': /* Close Complete */
>
> --- libpq-fe.h.2~ 2004-10-18 17:55:40.632064120 +0530
> +++ libpq-fe.h 2004-10-18 17:56:26.501634328 +0530
> @@ -312,9 +312,9 @@
> int resultFormat);
>
> /* Interface for multiple-result or asynchronous queries */
> -extern PGresult *PQsendPrepare(PGconn *conn, const char *stmtName,
> - const char *query, int nParams,
> - const Oid *paramTypes);
> +extern int PQsendPrepare(PGconn *conn, const char *stmtName,
> + const char *query, int nParams,
> + const Oid *paramTypes);
> extern int PQsendQuery(PGconn *conn, const char *query);
> extern int PQsendQueryParams(PGconn *conn,
> const char *command,
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faqs/FAQ.html
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Index: doc/src/sgml/libpq.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/libpq.sgml,v
retrieving revision 1.165
diff -c -c -r1.165 libpq.sgml
*** doc/src/sgml/libpq.sgml 1 Oct 2004 17:34:17 -0000 1.165
--- doc/src/sgml/libpq.sgml 18 Oct 2004 18:13:09 -0000
***************
*** 1183,1194 ****
</varlistentry>
</variablelist>
! Presently, prepared statements for use with <function>PQexecPrepared</>
! must be set up by executing an SQL <command>PREPARE</> command,
! which is typically sent with <function>PQexec</> (though any of
! <application>libpq</>'s query-submission functions may be used).
! A lower-level interface for preparing statements may be offered in a
! future release.
</para>
<para>
--- 1183,1238 ----
</varlistentry>
</variablelist>
! Prepared statements for use with <function>PQexecPrepared</> can be
! created by executing an SQL <command>PREPARE</> statement (which is
! sent with <function>PQexec</>, or one of the other query-submission
! functions), or with <function>PQprepare</>. The latter does not
! require parameter types to be pre-specified.
! </para>
!
! <para>
! <variablelist>
! <varlistentry>
! <term><function>PQprepare</function><indexterm><primary>PQprepare</></></term>
! <listitem>
! <para>
! Submits a request to create a prepared statement with the
! given parameters, and waits for completion.
! <synopsis>
! PGresult *PQprepare(PGconn *conn,
! const char *stmtName,
! const char *query,
! int nParams,
! const Oid *paramTypes);
! </synopsis>
! </para>
!
! <para>
! <function>PQprepare</> creates a prepared statement for execution with
! <function>PQexecPrepared</>. Unlike <command>PREPARE</>, it allows the
! client to prepare a statement without pre-specifying the types of each
! parameter. This function is supported only in protocol 3.0 and later
! connections; it will fail when using protocol 2.0.
! </para>
!
! <para>
! The function creates a prepared statement named <parameter>stmtName</>
! (which may be <literal>""</>, to refer to the unnamed statement) from
! the <parameter>query</>. If any parameters are used, they are referred
! to in the query as <literal>$1</>, <literal>$2</>, etc.
!
! <parameter>nParams</> is the number of parameters for which types are
! pre-specified in the array <parameter>paramTypes[]</>. It may be zero,
! or up to the number of parameters used in the query. Each entry in the
! <parameter>paramTypes[]</> array should contain the OID of the type of
! the corresponding parameter. If <parameter>nParams</> is 0, the server
! assigns a data type to each parameter, as it would for untyped literal
! strings. Likewise, if any element in the type array is zero, its type
! is inferred.
! </para>
! </listitem>
! </varlistentry>
! </variablelist>
</para>
<para>
***************
*** 2353,2358 ****
--- 2397,2423 ----
</varlistentry>
<varlistentry>
+ <term><function>PQsendPrepare</><indexterm><primary>PQsendPrepare</></></term>
+ <listitem>
+ <para>
+ Sends a request to create a prepared statement with the given
+ parameters, without waiting for completion.
+ <synopsis>
+ int PQsendPrepare(PGconn *conn,
+ const char *stmtName,
+ const char *query,
+ int nParams,
+ const Oid *paramTypes);
+ </synopsis>
+
+ This is an asynchronous version of <function>PQprepare</>, and
+ its parameters are handled identically. It will not work on 2.0
+ protocol connections.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
<term><function>PQgetResult</function><indexterm><primary>PQgetResult</></></term>
<listitem>
<para>
Index: src/interfaces/libpq/fe-exec.c
===================================================================
RCS file: /cvsroot/pgsql/src/interfaces/libpq/fe-exec.c,v
retrieving revision 1.163
diff -c -c -r1.163 fe-exec.c
*** src/interfaces/libpq/fe-exec.c 16 Oct 2004 22:52:53 -0000 1.163
--- src/interfaces/libpq/fe-exec.c 18 Oct 2004 18:13:23 -0000
***************
*** 635,640 ****
--- 635,704 ----
/*
+ * PQsendPrepare
+ * Submit a Parse message, but don't wait for it to finish.
+ *
+ * Returns: 1 if successfully submitted
+ * 0 if error (conn->errorMessage is set)
+ */
+ int
+ PQsendPrepare(PGconn *conn,
+ const char *stmtName, const char *query,
+ int nParams, const Oid *paramTypes)
+ {
+ if (PG_PROTOCOL_MAJOR(conn->pversion) < 3)
+ {
+ printfPQExpBuffer(&conn->errorMessage,
+ libpq_gettext("function requires at least protocol version 3.0\n"));
+ return 0;
+ }
+
+ if (!PQsendQueryStart(conn))
+ return 0;
+
+ if (pqPutMsgStart('P', false, conn) < 0 ||
+ pqPuts(stmtName, conn) < 0 ||
+ pqPuts(query, conn) < 0)
+ goto sendFailed;
+
+ if (nParams > 0 && paramTypes)
+ {
+ int i;
+
+ if (pqPutInt(nParams, 2, conn) < 0)
+ goto sendFailed;
+ for (i = 0; i < nParams; i++)
+ {
+ if (pqPutInt(paramTypes[i], 4, conn) < 0)
+ goto sendFailed;
+ }
+ }
+ else
+ {
+ if (pqPutInt(0, 2, conn) < 0)
+ goto sendFailed;
+ }
+ if (pqPutMsgEnd(conn) < 0)
+ goto sendFailed;
+
+ if (pqPutMsgStart('S', false, conn) < 0 ||
+ pqPutMsgEnd(conn) < 0)
+ goto sendFailed;
+
+ conn->ext_query = true;
+ conn->sent_prepare = true;
+ if (pqFlush(conn) < 0)
+ goto sendFailed;
+ conn->asyncStatus = PGASYNC_BUSY;
+ return 1;
+
+ sendFailed:
+ pqHandleSendFailure(conn);
+ return 0;
+ }
+
+
+ /*
* PQsendQuery
* Submit a query, but don't wait for it to finish
*
***************
*** 1145,1150 ****
--- 1209,1236 ----
return PQexecFinish(conn);
}
+
+ /*
+ * PQprepare
+ * Creates a prepared statement by issuing a v3.0 parse message.
+ *
+ * Returns NULL if the query failed, and a new PGresult otherwise. The
+ * user is responsible for calling PQclient() on the result.
+ */
+
+ PGresult *
+ PQprepare(PGconn *conn,
+ const char *stmtName, const char *query,
+ int nParams, const Oid *paramTypes)
+ {
+ if (!PQexecStart(conn))
+ return NULL;
+ if (!PQsendPrepare(conn, stmtName, query, nParams, paramTypes))
+ return NULL;
+ return PQexecFinish(conn);
+ }
+
+
/*
* PQexecParams
* Like PQexec, but use protocol 3.0 so we can pass parameters
Index: src/interfaces/libpq/fe-protocol3.c
===================================================================
RCS file: /cvsroot/pgsql/src/interfaces/libpq/fe-protocol3.c,v
retrieving revision 1.18
diff -c -c -r1.18 fe-protocol3.c
*** src/interfaces/libpq/fe-protocol3.c 16 Oct 2004 22:52:54 -0000 1.18
--- src/interfaces/libpq/fe-protocol3.c 18 Oct 2004 18:13:26 -0000
***************
*** 220,225 ****
--- 220,233 ----
conn->asyncStatus = PGASYNC_READY;
break;
case '1': /* Parse Complete */
+ if (conn->sent_prepare) {
+ if (!conn->result)
+ conn->result = PQmakeEmptyPGresult(conn,
+ PGRES_COMMAND_OK);
+ conn->asyncStatus = PGASYNC_READY;
+ conn->sent_prepare = false;
+ }
+ break;
case '2': /* Bind Complete */
case '3': /* Close Complete */
/* Nothing to do for these message types */
Index: src/interfaces/libpq/libpq-fe.h
===================================================================
RCS file: /cvsroot/pgsql/src/interfaces/libpq/libpq-fe.h,v
retrieving revision 1.111
diff -c -c -r1.111 libpq-fe.h
*** src/interfaces/libpq/libpq-fe.h 16 Oct 2004 22:52:55 -0000 1.111
--- src/interfaces/libpq/libpq-fe.h 18 Oct 2004 18:13:28 -0000
***************
*** 296,301 ****
--- 296,304 ----
/* Simple synchronous query */
extern PGresult *PQexec(PGconn *conn, const char *query);
+ extern PGresult *PQprepare(PGconn *conn, const char *stmtName,
+ const char *query, int nParams,
+ const Oid *paramTypes);
extern PGresult *PQexecParams(PGconn *conn,
const char *command,
int nParams,
***************
*** 313,318 ****
--- 316,324 ----
int resultFormat);
/* Interface for multiple-result or asynchronous queries */
+ extern int PQsendPrepare(PGconn *conn, const char *stmtName,
+ const char *query, int nParams,
+ const Oid *paramTypes);
extern int PQsendQuery(PGconn *conn, const char *query);
extern int PQsendQueryParams(PGconn *conn,
const char *command,
Index: src/interfaces/libpq/libpq-int.h
===================================================================
RCS file: /cvsroot/pgsql/src/interfaces/libpq/libpq-int.h,v
retrieving revision 1.94
diff -c -c -r1.94 libpq-int.h
*** src/interfaces/libpq/libpq-int.h 16 Oct 2004 22:52:55 -0000 1.94
--- src/interfaces/libpq/libpq-int.h 18 Oct 2004 18:13:29 -0000
***************
*** 268,273 ****
--- 268,275 ----
* nonblock sending semantics */
bool ext_query; /* was our last query sent with extended
* query protocol? */
+ bool sent_prepare; /* was our last Parse message sent with
+ * PQprepare? */
char copy_is_binary; /* 1 = copy binary, 0 = copy text */
int copy_already_done; /* # bytes already returned in
* COPY OUT */
/*
* Test program for PQprepare/PQdescribe.
* Abhijit Menon-Sen <ams@oryx.com>
*
* create table pqtest (a int, b text, c text);
* insert into pqtest (a,b,c) values (1,'foo','bar');
* insert into pqtest (a,b,c) values (1,'foo','baz');
* insert into pqtest (a,b,c) values (2,'foo','barf');
*/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include "libpq-fe.h"
int main(int argc, char *argv[])
{
int i, a, b, c;
PGconn *conn;
PGresult *res;
char *query = "select * from pqtest where a=$1 and b=$2";
const char *values[2];
conn = PQconnectdb("");
if (PQstatus(conn) != CONNECTION_OK) {
fprintf(stderr, "Couldn't connect to the database: %s",
PQerrorMessage(conn));
PQfinish(conn);
exit(-1);
}
res = PQprepare(conn, "prep", query, 0, NULL);
if (PQresultStatus(res) != PGRES_COMMAND_OK) {
fprintf(stderr, "PREPARE failed: %s", PQerrorMessage(conn));
PQclear(res);
PQfinish(conn);
exit(-1);
}
PQclear(res);
values[0] = "1";
values[1] = "foo";
res = PQexecPrepared(conn, "prep", 2, values, NULL, NULL, 0);
if (PQresultStatus(res) != PGRES_TUPLES_OK) {
fprintf(stderr, "EXECUTE failed: %s", PQerrorMessage(conn));
PQclear(res);
PQfinish(conn);
exit(-1);
}
a = PQfnumber(res, "a");
b = PQfnumber(res, "b");
c = PQfnumber(res, "c");
printf("Results:\n");
for(i = 0; i < PQntuples(res); i++) {
char *av = PQgetvalue(res, i, a);
char *bv = PQgetvalue(res, i, b);
char *cv = PQgetvalue(res, i, c);
printf(" (a=%s)(b=%s)(c=%s)\n", av, bv, cv);
}
printf("%d rows\n", i);
PQclear(res);
PQfinish(conn);
return 0;
}
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Here is a mega-patch that merges in your four previous patches. Is this
> ready to be applied? Making libpq changes during beta is risky so we
> had better be careful.
I was planning to review the updated patch and apply if there was
nothing else major wrong with it. I will use this as the starting
point --- thanks for doing the merging ...
regards, tom lane
Abhijit Menon-Sen <ams@oryx.com> writes:
> At 2004-10-16 18:41:05 -0400, tgl@sss.pgh.pa.us wrote:
>> I think the cleanest solution is probably to add a state flag indicating
>> whether ParseComplete should generate a PGresult or not.
> Like the appended (incremental) patch?
Not exactly --- the way you've got this set up, a failed PQprepare will
leave a booby trap for the next operation. The flag has got to be reset
on command send, not on receipt of a success response. I'll find a
better place to do it.
regards, tom lane