Nearing final release?

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

-----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.

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, Pennsylvania 19073

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, Pennsylvania 19073

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;		/* 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,

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

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

Here's the patch actually applied. I cleaned up the state problem,
fixed a couple minor omissions in the code, and did some work on the
documentation; also updated exports.txt which is now the source for
the *.def files.

regards, tom lane

*** doc/src/sgml/libpq.sgml.orig	Fri Oct  1 13:34:17 2004
--- doc/src/sgml/libpq.sgml	Mon Oct 18 17:50:04 2004
***************
*** 1055,1062 ****
            out-of-memory conditions or serious errors such as inability
            to send the command to the server.
            If a null pointer is returned, it
!           should be treated like a <symbol>PGRES_FATAL_ERROR</symbol> result.  Use
!           <function>PQerrorMessage</function> to get more information about the error.
  </para>
  </listitem>
  </varlistentry>
--- 1055,1063 ----
            out-of-memory conditions or serious errors such as inability
            to send the command to the server.
            If a null pointer is returned, it
!           should be treated like a <symbol>PGRES_FATAL_ERROR</symbol> result.
!           Use <function>PQerrorMessage</function> to get more information
!           about such errors.
  </para>
  </listitem>
  </varlistentry>
***************
*** 1147,1152 ****
--- 1148,1228 ----
  <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 later execution with
+ <function>PQexecPrepared</>.
+ This feature allows commands
+ that will be used repeatedly to be parsed and planned just once, rather
+ than each time they are executed.
+ <function>PQprepare</> 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</>
+ from the <parameter>query</> string, which must contain a single SQL command.
+ <parameter>stmtName</> may be <literal>""</> to create an unnamed statement,
+ in which case any pre-existing unnamed statement is automatically replaced;
+ otherwise it is an error if the statement name is already defined in the
+ current session.
+ 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[]</>.  (The array pointer
+ may be <symbol>NULL</symbol> when <parameter>nParams</> is zero.)
+ <parameter>paramTypes[]</> specifies, by OID, the data types to be assigned to
+ the parameter symbols.  If <parameter>paramTypes</> is <symbol>NULL</symbol>,
+ or any particular element in the array is zero, the server assigns a data type
+ to the parameter symbol in the same way it would do for an untyped literal
+ string.  Also, the query may use parameter symbols with numbers higher than
+ <parameter>nParams</>; data types will be inferred for these symbols as
+ well.
+ </para>
+ 
+ <para>
+ As with <function>PQexec</>, the result is normally a
+ <structname>PGresult</structname> object whose contents indicate server-side
+ success or failure.  A null result indicates out-of-memory or inability to
+ send the command at all.
+ Use <function>PQerrorMessage</function> to get more information
+ about such errors.
+ </para>
+ 
+ <para>
+ At present, there is no way to determine the actual datatype inferred for
+ any parameters whose types are not specified in <parameter>paramTypes[]</>.
+ This is a <application>libpq</> omission that will probably be rectified
+ in a future release.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ 
+ Prepared statements for use with <function>PQexecPrepared</> can also be
+ created by executing SQL <command>PREPARE</> statements.  (But
+ <function>PQprepare</> is more flexible since it does not require
+ parameter types to be pre-specified.)  Also, although there is no
+ <application>libpq</> function for deleting a prepared statement,
+ the SQL <command>DEALLOCATE</> statement can be used for that purpose.
+ </para>
+ 
+ <para>
+ <variablelist>
+ <varlistentry>
  <term><function>PQexecPrepared</function><indexterm><primary>PQexecPrepared</></></term>
  <listitem>
  <para>
***************
*** 1166,1172 ****
  <para>
  <function>PQexecPrepared</> is like <function>PQexecParams</>, but the
  command to be executed is specified by naming a previously-prepared
! statement, instead of giving a query string.  This feature allows commands
  that will be used repeatedly to be parsed and planned just once, rather
  than each time they are executed.
  <function>PQexecPrepared</> is supported only in protocol 3.0 and later
--- 1242,1249 ----
  <para>
  <function>PQexecPrepared</> is like <function>PQexecParams</>, but the
  command to be executed is specified by naming a previously-prepared
! statement, instead of giving a query string.
! This feature allows commands
  that will be used repeatedly to be parsed and planned just once, rather
  than each time they are executed.
  <function>PQexecPrepared</> is supported only in protocol 3.0 and later
***************
*** 1182,1194 ****
  </listitem>
  </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>
--- 1259,1264 ----
***************
*** 2270,2279 ****
  Applications that do not like these limitations can instead use the
  underlying functions that <function>PQexec</function> is built from:
  <function>PQsendQuery</function> and <function>PQgetResult</function>.
! There are also <function>PQsendQueryParams</function> and
! <function>PQsendQueryPrepared</function>, which can be used with
! <function>PQgetResult</function> to duplicate the functionality of
! <function>PQexecParams</function> and <function>PQexecPrepared</function>
  respectively.

  <variablelist>
--- 2340,2354 ----
  Applications that do not like these limitations can instead use the
  underlying functions that <function>PQexec</function> is built from:
  <function>PQsendQuery</function> and <function>PQgetResult</function>.
! There are also
! <function>PQsendQueryParams</function>,
! <function>PQsendPrepare</function>, and
! <function>PQsendQueryPrepared</function>,
! which can be used with <function>PQgetResult</function> to duplicate the
! functionality of
! <function>PQexecParams</function>,
! <function>PQprepare</function>, and
! <function>PQexecPrepared</function>
  respectively.

  <variablelist>
***************
*** 2326,2331 ****
--- 2401,2433 ----
  </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</>: it
+         returns 1 if it was able to dispatch the request, and 0 if not.
+         After a successful call, call <function>PQgetResult</function>
+         to determine whether the server successfully created the prepared
+         statement.
+         The function's parameters are handled identically to
+         <function>PQprepare</function>.  Like
+         <function>PQprepare</function>, it will not work on 2.0-protocol
+         connections.
+ </para>
+ </listitem>
+ </varlistentry>
+ 
+ <varlistentry>
  <term><function>PQsendQueryPrepared</function><indexterm><primary>PQsendQueryPrepared</></></term>
  <listitem>
  <para>
***************
*** 2358,2364 ****
  <para>
            Waits for the next result from a prior
            <function>PQsendQuery</function>,
!           <function>PQsendQueryParams</function>, or
            <function>PQsendQueryPrepared</function> call,
            and returns it.  A null pointer is returned when the command is complete
            and there will be no more results.
--- 2460,2467 ----
  <para>
            Waits for the next result from a prior
            <function>PQsendQuery</function>,
!           <function>PQsendQueryParams</function>,
!           <function>PQsendPrepare</function>, or
            <function>PQsendQueryPrepared</function> call,
            and returns it.  A null pointer is returned when the command is complete
            and there will be no more results.
*** src/interfaces/libpq/exports.txt.orig	Sat Oct 16 16:03:45 2004
--- src/interfaces/libpq/exports.txt	Mon Oct 18 17:36:43 2004
***************
*** 1,3 ****
--- 1,4 ----
+ # $PostgreSQL$
  # Functions to be exported by libpq DLLs
  PQconnectdb               1
  PQsetdbLogin              2
***************
*** 116,118 ****
--- 117,121 ----
  pg_char_to_encoding       115
  pg_valid_server_encoding  116
  pqsignal                  117
+ PQprepare                 118
+ PQsendPrepare             119
*** src/interfaces/libpq/fe-exec.c.orig	Sat Oct 16 18:52:53 2004
--- src/interfaces/libpq/fe-exec.c	Mon Oct 18 17:35:24 2004
***************
*** 664,670 ****
  	}

/* remember we are using simple query protocol */
! conn->ext_query = false;

  	/*
  	 * Give the data a push.  In nonblock mode, don't complain if we're
--- 664,670 ----
  	}

/* remember we are using simple query protocol */
! conn->queryclass = PGQUERY_SIMPLE;

  	/*
  	 * Give the data a push.  In nonblock mode, don't complain if we're
***************
*** 718,723 ****
--- 718,811 ----
  }

  /*
+  * 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 (!PQsendQueryStart(conn))
+ 		return 0;
+ 
+ 	if (!stmtName)
+ 	{
+ 		printfPQExpBuffer(&conn->errorMessage,
+ 					libpq_gettext("statement name is a null pointer\n"));
+ 		return 0;
+ 	}
+ 
+ 	if (!query)
+ 	{
+ 		printfPQExpBuffer(&conn->errorMessage,
+ 					libpq_gettext("command string is a null pointer\n"));
+ 		return 0;
+ 	}
+ 
+ 	/* This isn't gonna work on a 2.0 server */
+ 	if (PG_PROTOCOL_MAJOR(conn->pversion) < 3)
+ 	{
+ 		printfPQExpBuffer(&conn->errorMessage,
+ 						  libpq_gettext("function requires at least protocol version 3.0\n"));
+ 		return 0;
+ 	}
+ 
+ 	/* construct the Parse message */
+ 	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;
+ 
+ 	/* construct the Sync message */
+ 	if (pqPutMsgStart('S', false, conn) < 0 ||
+ 		pqPutMsgEnd(conn) < 0)
+ 		goto sendFailed;
+ 
+ 	/* remember we are doing just a Parse */
+ 	conn->queryclass = PGQUERY_PREPARE;
+ 
+ 	/*
+ 	 * Give the data a push.  In nonblock mode, don't complain if we're
+ 	 * unable to send it all; PQgetResult() will do any additional
+ 	 * flushing needed.
+ 	 */
+ 	if (pqFlush(conn) < 0)
+ 		goto sendFailed;
+ 
+ 	/* OK, it's launched! */
+ 	conn->asyncStatus = PGASYNC_BUSY;
+ 	return 1;
+ 
+ sendFailed:
+ 	pqHandleSendFailure(conn);
+ 	return 0;
+ }
+ 
+ /*
   * PQsendQueryPrepared
   *		Like PQsendQuery, but execute a previously prepared statement,
   *		using protocol 3.0 so we can pass parameters
***************
*** 921,927 ****
  		goto sendFailed;

/* remember we are using extended query protocol */
! conn->ext_query = true;

  	/*
  	 * Give the data a push.  In nonblock mode, don't complain if we're
--- 1009,1015 ----
  		goto sendFailed;

/* remember we are using extended query protocol */
! conn->queryclass = PGQUERY_EXTENDED;

  	/*
  	 * Give the data a push.  In nonblock mode, don't complain if we're
***************
*** 1134,1140 ****
   * The user is responsible for freeing the PGresult via PQclear()
   * when done with it.
   */
- 
  PGresult *
  PQexec(PGconn *conn, const char *query)
  {
--- 1222,1227 ----
***************
*** 1169,1174 ****
--- 1256,1284 ----
  }

  /*
+  * PQprepare
+  *    Creates a prepared statement by issuing a v3.0 parse message.
+  *
+  * If the query was not even sent, return NULL; conn->errorMessage is set to
+  * a relevant message.
+  * If the query was sent, a new PGresult is returned (which could indicate
+  * either success or failure).
+  * The user is responsible for freeing the PGresult via PQclear()
+  * when done with it.
+  */
+ 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);
+ }
+ 
+ /*
   * PQexecPrepared
   *		Like PQexec, but execute a previously prepared statement,
   *		using protocol 3.0 so we can pass parameters
***************
*** 1451,1457 ****
  		 * If we sent the COPY command in extended-query mode, we must
  		 * issue a Sync as well.
  		 */
! 		if (conn->ext_query)
  		{
  			if (pqPutMsgStart('S', false, conn) < 0 ||
  				pqPutMsgEnd(conn) < 0)
--- 1561,1567 ----
  		 * If we sent the COPY command in extended-query mode, we must
  		 * issue a Sync as well.
  		 */
! 		if (conn->queryclass != PGQUERY_SIMPLE)
  		{
  			if (pqPutMsgStart('S', false, conn) < 0 ||
  				pqPutMsgEnd(conn) < 0)
*** src/interfaces/libpq/fe-protocol3.c.orig	Sat Oct 16 18:52:54 2004
--- src/interfaces/libpq/fe-protocol3.c	Mon Oct 18 17:35:24 2004
***************
*** 220,225 ****
--- 220,234 ----
  					conn->asyncStatus = PGASYNC_READY;
  					break;
  				case '1':		/* Parse Complete */
+ 					/* If we're doing PQprepare, we're done; else ignore */
+ 					if (conn->queryclass == PGQUERY_PREPARE)
+ 					{
+ 						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 */
***************
*** 1118,1124 ****
  		 * If we sent the COPY command in extended-query mode, we must
  		 * issue a Sync as well.
  		 */
! 		if (conn->ext_query)
  		{
  			if (pqPutMsgStart('S', false, conn) < 0 ||
  				pqPutMsgEnd(conn) < 0)
--- 1127,1133 ----
  		 * If we sent the COPY command in extended-query mode, we must
  		 * issue a Sync as well.
  		 */
! 		if (conn->queryclass != PGQUERY_SIMPLE)
  		{
  			if (pqPutMsgStart('S', false, conn) < 0 ||
  				pqPutMsgEnd(conn) < 0)
*** src/interfaces/libpq/libpq-fe.h.orig	Sat Oct 16 18:52:55 2004
--- src/interfaces/libpq/libpq-fe.h	Mon Oct 18 17:35:24 2004
***************
*** 304,309 ****
--- 304,312 ----
  			 const int *paramLengths,
  			 const int *paramFormats,
  			 int resultFormat);
+ extern PGresult *PQprepare(PGconn *conn, const char *stmtName,
+ 						   const char *query, int nParams,
+ 						   const Oid *paramTypes);
  extern PGresult *PQexecPrepared(PGconn *conn,
  			   const char *stmtName,
  			   int nParams,
***************
*** 322,327 ****
--- 325,333 ----
  				  const int *paramLengths,
  				  const int *paramFormats,
  				  int resultFormat);
+ extern int PQsendPrepare(PGconn *conn, const char *stmtName,
+ 						 const char *query, int nParams,
+ 						 const Oid *paramTypes);
  extern int PQsendQueryPrepared(PGconn *conn,
  					const char *stmtName,
  					int nParams,
*** src/interfaces/libpq/libpq-int.h.orig	Sat Oct 16 18:52:55 2004
--- src/interfaces/libpq/libpq-int.h	Mon Oct 18 17:35:25 2004
***************
*** 185,190 ****
--- 185,198 ----
  	PGASYNC_COPY_OUT			/* Copy Out data transfer in progress */
  } PGAsyncStatusType;

+ /* PGQueryClass tracks which query protocol we are now executing */
+ typedef enum
+ {
+ 	PGQUERY_SIMPLE,				/* simple Query protocol (PQexec) */
+ 	PGQUERY_EXTENDED,			/* full Extended protocol (PQexecParams) */
+ 	PGQUERY_PREPARE				/* Parse only (PQprepare) */
+ } PGQueryClass;
+ 
  /* PGSetenvStatusType defines the state of the PQSetenv state machine */
  /* (this is used only for 2.0-protocol connections) */
  typedef enum
***************
*** 264,273 ****
  	PGAsyncStatusType asyncStatus;
  	PGTransactionStatusType xactStatus;
  	/* note: xactStatus never changes to ACTIVE */
  	bool		nonblocking;	/* whether this connection is using
  								 * nonblock sending semantics */
- 	bool		ext_query;		/* was our last query sent with extended
- 								 * query protocol? */
  	char		copy_is_binary; /* 1 = copy binary, 0 = copy text */
  	int			copy_already_done;		/* # bytes already returned in
  										 * COPY OUT */
--- 272,280 ----
  	PGAsyncStatusType asyncStatus;
  	PGTransactionStatusType xactStatus;
  	/* note: xactStatus never changes to ACTIVE */
+ 	PGQueryClass queryclass;
  	bool		nonblocking;	/* whether this connection is using
  								 * nonblock sending semantics */
  	char		copy_is_binary; /* 1 = copy binary, 0 = copy text */
  	int			copy_already_done;		/* # bytes already returned in
  										 * COPY OUT */