Skip to content
Snippets Groups Projects
Commit a9a999bc authored by Tom Lane's avatar Tom Lane
Browse files

Remove obsolete remark that PQprepare() is more flexible than PREPARE.

Spotted by Dmitriy Igrishin.  Back-patch to 8.2, which is when the PREPARE
statement was improved to allow parameter types to be omitted.
parent 462583be
No related branches found
No related tags found
No related merge requests found
<!-- $PostgreSQL: pgsql/doc/src/sgml/libpq.sgml,v 1.321 2010/08/17 04:37:20 petere Exp $ --> <!-- $PostgreSQL: pgsql/doc/src/sgml/libpq.sgml,v 1.322 2010/08/29 15:19:05 tgl Exp $ -->
<chapter id="libpq"> <chapter id="libpq">
<title><application>libpq</application> - C Library</title> <title><application>libpq</application> - C Library</title>
...@@ -1895,9 +1895,7 @@ PGresult *PQprepare(PGconn *conn, ...@@ -1895,9 +1895,7 @@ PGresult *PQprepare(PGconn *conn,
Prepared statements for use with <function>PQexecPrepared</> can also Prepared statements for use with <function>PQexecPrepared</> can also
be created by executing SQL <xref linkend="sql-prepare"> be created by executing SQL <xref linkend="sql-prepare">
statements. (But <function>PQprepare</> statements. Also, although there is no <application>libpq</>
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 <xref function for deleting a prepared statement, the SQL <xref
linkend="sql-deallocate"> statement linkend="sql-deallocate"> statement
can be used for that purpose. can be used for that purpose.
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment