+ PQescapeString> is an older, deprecated version of
+ PQescapeStringConn>.
size_t PQescapeString (char *to, const char *from, size_t length);
- PQescapeString> is an older, deprecated version of
- PQescapeStringConn>; the difference is that it does
-
not take conn> or
error> parameters.
+ The only difference from PQescapeStringConn> is that
+ PQescapeString> does not take PGconn>
Because of this, it cannot adjust its behavior depending on the
connection properties (such as character encoding) and therefore
it might give the wrong results>. Also, it has no way
- PQescapeString> can be used safely in single-threaded
+ PQescapeString> can be used safely in
client programs that work with only one
PostgreSQL>
connection at a time (in this case it can find out what it needs to
know behind the scenes>). In other contexts it is a security
- Certain byte values must be escaped (but all
- byte values can be escaped) when used as part
- of a
bytea literal in an
SQL
- statement. In general, to escape a byte, it is converted into the
- three digit octal number equal to the octet value, and preceded by
- usually two backslashes. The single quote ('>) and backslash
- (\>) characters have special alternative escape
- sequences. See for more
- information. PQescapeByteaConn performs this
- operation, escaping only the minimally required bytes.
+ Certain byte values must be escaped when used as part of a
+
bytea literal in an
SQL statement.
+ PQescapeByteaConn escapes bytes using
+ either hex encoding or backslash escaping. See
+ linkend="datatype-binary"> for more information.
The only difference from PQescapeByteaConn> is that
PQescapeBytea> does not take a PGconn>
- parameter. Because of this, it cannot adjust its behavior
- depending on the connection properties (in particular, whether
- standard-conforming strings are enabled) and therefore
- it might give the wrong results>. Also, it has no
- way to return an error message on failure.
-
-
- PQescapeBytea> can be used safely in single-threaded
- client programs that work with only one
PostgreSQL>
- connection at a time (in this case it can find out what it needs
- to know behind the scenes>). In other contexts it is
- a security hazard and should be avoided in favor of
- PQescapeByteaConn>.
+ parameter. Because of this, PQescapeBytea> can
+ only be used safely in client programs that use a single
+
PostgreSQL> connection at a time (in this case
+ it can find out what it needs to know behind the
+ scenes>). It might give the wrong results> if
+ used in programs that use multiple database connections (use
+ PQescapeByteaConn> in such cases).
whether hex or traditional format is used for bytea>
output. Libpq's PQescapeByteaConn()> function automatically
uses the hex format when connected to
PostgreSQL> 9.0
- or newer servers.
+ or newer servers. However, pre-9.0 libpq versions will not
+ correctly process hex format from newer servers.