string literals, much like
      <xref linkend="libpq-PQescapeLiteral"/>.  Unlike <xref linkend="libpq-PQescapeLiteral"/>,
      the caller is responsible for providing an appropriately sized buffer.
      Furthermore, <xref linkend="libpq-PQescapeStringConn"/> does not generate the
      single quotes that must surround <productname>PostgreSQL</productname> string
      literals; they should be provided in the SQL command that the
      result is inserted into.  The parameter <parameter>from</parameter> points to
      the first character of the string that is to be escaped, and the
      <parameter>length</parameter> parameter gives the number of bytes in this
      string.  A terminating zero byte is not required, and should not be
      counted in <parameter>length</parameter>.  (If a terminating zero byte is found
      before <parameter>length</parameter> bytes are processed,
      <xref linkend="libpq-PQescapeStringConn"/> stops at the zero; the behavior is
      thus rather like <function>strncpy</function>.) <parameter>to</parameter> shall point
      to a buffer that is able to hold at least one more byte than twice
      the value of <parameter>length</parameter>, otherwise the behavior is undefined.
      Behavior is likewise undefined if the <parameter>to</parameter> and
      <parameter>from</parameter> strings overlap.
     </para>

     <para>
      If the <parameter>error</parameter> parameter is not <symbol>NULL</symbol>, then
      <literal>*error</literal> is set to zero on success, nonzero on error.
      Presently the only possible error conditions involve invalid multibyte
      encoding in the source string.  The output string is still generated
      on error, but it can be expected that the server will reject it as
      malformed.  On error, a suitable message is stored in the
      <parameter>conn</parameter> object, whether or not <parameter>error</parameter> is <symbol>NULL</symbol>.
     </para>

     <para>
      <xref linkend="libpq-PQescapeStringConn"/> returns the number of bytes written
      to <parameter>to</parameter>, not including the terminating zero byte.
     </para>
     </listitem>
    </varlistentry>

    <varlistentry id="libpq-PQescapeString">
     <term><function>PQescapeString</function><indexterm><primary>PQescapeString</primary></indexterm></term>

     <listitem>
     <para>
       <xref linkend="libpq-PQescapeString"/> is an older, deprecated version of
       <xref linkend="libpq-PQescapeStringConn"/>.
<synopsis>
size_t PQescapeString (char *to, const char *from, size_t length);
</synopsis>
     </para>

     <para>
      The only difference from <xref linkend="libpq-PQescapeStringConn"/> is that
      <xref linkend="libpq-PQescapeString"/> does not take <structname>PGconn</structname>
      or <parameter>error</parameter> parameters.
      Because of this, it cannot adjust its behavior depending on the
      connection properties (such as character encoding) and therefore
      <emphasis>it might give the wrong results</emphasis>.  Also, it has no way
      to report error conditions.
     </para>

     <para>
      <xref linkend="libpq-PQescapeString"/> can be used safely in
      client programs that work with only one <productname>PostgreSQL</productname>
      connection at a time (in this case it can find out what it needs to
      know <quote>behind the scenes</quote>).  In other contexts it is a security
      hazard and should be avoided in favor of
      <xref linkend="libpq-PQescapeStringConn"/>.
     </para>
     </listitem>
    </varlistentry>

    <varlistentry id="libpq-PQescapeByteaConn">
     <term><function>PQescapeByteaConn</function><indexterm><primary>PQescapeByteaConn</primary></indexterm></term>

     <listitem>
     <para>
       Escapes binary data for use within an SQL command with the type
       <type>bytea</type>.  As with <xref linkend="libpq-PQescapeStringConn"/>,
       this is only used when inserting data directly into an SQL command string.