@@ -3385,23 +3385,25 @@ size_t PQescapeStringConn(PGconn *conn,
33853385
33863386 <listitem>
33873387 <para>
3388+ <function>PQescapeString</> is an older, deprecated version of
3389+ <function>PQescapeStringConn</>.
33883390<synopsis>
33893391size_t PQescapeString (char *to, const char *from, size_t length);
33903392</synopsis>
33913393 </para>
33923394
33933395 <para>
3394- <function>PQescapeString </> isan older, deprecated version of
3395- <function>PQescapeStringConn </>; the difference is that it does
3396- not take <parameter>conn</> or <parameter>error</> parameters.
3396+ The only difference from <function>PQescapeStringConn </> isthat
3397+ <function>PQescapeString </> does not take <structname>PGconn</>
3398+ or <parameter>error</> parameters.
33973399 Because of this, it cannot adjust its behavior depending on the
33983400 connection properties (such as character encoding) and therefore
33993401 <emphasis>it might give the wrong results</>. Also, it has no way
34003402 to report error conditions.
34013403 </para>
34023404
34033405 <para>
3404- <function>PQescapeString</> can be used safely in single-threaded
3406+ <function>PQescapeString</> can be used safely in
34053407 client programs that work with only one <productname>PostgreSQL</>
34063408 connection at a time (in this case it can find out what it needs to
34073409 know <quote>behind the scenes</>). In other contexts it is a security
@@ -3433,16 +3435,11 @@ unsigned char *PQescapeByteaConn(PGconn *conn,
34333435 </para>
34343436
34353437 <para>
3436- Certain byte values <emphasis>must</emphasis> be escaped (but all
3437- byte values <emphasis>can</emphasis> be escaped) when used as part
3438- of a <type>bytea</type> literal in an <acronym>SQL</acronym>
3439- statement. In general, to escape a byte, it is converted into the
3440- three digit octal number equal to the octet value, and preceded by
3441- usually two backslashes. The single quote (<literal>'</>) and backslash
3442- (<literal>\</>) characters have special alternative escape
3443- sequences. See <xref linkend="datatype-binary"> for more
3444- information. <function>PQescapeByteaConn</function> performs this
3445- operation, escaping only the minimally required bytes.
3438+ Certain byte values must be escaped when used as part of a
3439+ <type>bytea</type> literal in an <acronym>SQL</acronym> statement.
3440+ <function>PQescapeByteaConn</function> escapes bytes using
3441+ either hex encoding or backslash escaping. See <xref
3442+ linkend="datatype-binary"> for more information.
34463443 </para>
34473444
34483445 <para>
@@ -3499,20 +3496,13 @@ unsigned char *PQescapeBytea(const unsigned char *from,
34993496 <para>
35003497 The only difference from <function>PQescapeByteaConn</> is that
35013498 <function>PQescapeBytea</> does not take a <structname>PGconn</>
3502- parameter. Because of this, it cannot adjust its behavior
3503- depending on the connection properties (in particular, whether
3504- standard-conforming strings are enabled) and therefore
3505- <emphasis>it might give the wrong results</>. Also, it has no
3506- way to return an error message on failure.
3507- </para>
3508-
3509- <para>
3510- <function>PQescapeBytea</> can be used safely in single-threaded
3511- client programs that work with only one <productname>PostgreSQL</>
3512- connection at a time (in this case it can find out what it needs
3513- to know <quote>behind the scenes</>). In other contexts it is
3514- a security hazard and should be avoided in favor of
3515- <function>PQescapeByteaConn</>.
3499+ parameter. Because of this, <function>PQescapeBytea</> can
3500+ only be used safely in client programs that use a single
3501+ <productname>PostgreSQL</> connection at a time (in this case
3502+ it can find out what it needs to know <quote>behind the
3503+ scenes</>). It <emphasis>might give the wrong results</> if
3504+ used in programs that use multiple database connections (use
3505+ <function>PQescapeByteaConn</> in such cases).
35163506 </para>
35173507 </listitem>
35183508 </varlistentry>