message
       is stored in the <parameter>conn</parameter> object.  Currently, the only
       possible error is insufficient memory for the result string.
      </para>
     </listitem>
    </varlistentry>

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

     <listitem>
      <para>
       <xref linkend="libpq-PQescapeBytea"/> is an older, deprecated version of
       <xref linkend="libpq-PQescapeByteaConn"/>.
<synopsis>
unsigned char *PQescapeBytea(const unsigned char *from,
                             size_t from_length,
                             size_t *to_length);
</synopsis>
      </para>

      <para>
       The only difference from <xref linkend="libpq-PQescapeByteaConn"/> is that
       <xref linkend="libpq-PQescapeBytea"/> does not take a <structname>PGconn</structname>
       parameter.  Because of this, <xref linkend="libpq-PQescapeBytea"/> can
       only be used safely in client programs that use a single
       <productname>PostgreSQL</productname> connection at a time (in this case
       it can find out what it needs to know <quote>behind the
       scenes</quote>).  It <emphasis>might give the wrong results</emphasis> if
       used in programs that use multiple database connections (use
       <xref linkend="libpq-PQescapeByteaConn"/> in such cases).
      </para>
     </listitem>
    </varlistentry>

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

     <listitem>
      <para>
       Converts a string representation of binary data into binary data
       &mdash; the reverse of <xref linkend="libpq-PQescapeBytea"/>.  This
       is needed when retrieving <type>bytea</type> data in text format,
       but not when retrieving it in binary format.

<synopsis>
unsigned char *PQunescapeBytea(const unsigned char *from, size_t *to_length);
</synopsis>
      </para>

      <para>
       The <parameter>from</parameter> parameter points to a string
       such as might be returned by <xref linkend="libpq-PQgetvalue"/> when applied
       to a <type>bytea</type> column. <xref linkend="libpq-PQunescapeBytea"/>
       converts this string representation into its binary representation.
       It returns a pointer to a buffer allocated with
       <function>malloc()</function>, or <symbol>NULL</symbol> on error, and puts the size of
       the buffer in <parameter>to_length</parameter>. The result must be
       freed using <xref linkend="libpq-PQfreemem"/> when it is no longer needed.
      </para>

      <para>
       This conversion is not exactly the inverse of
       <xref linkend="libpq-PQescapeBytea"/>, because the string is not expected
       to be <quote>escaped</quote> when received from <xref linkend="libpq-PQgetvalue"/>.
       In particular this means there is no need for string quoting considerations,
       and so no need for a <structname>PGconn</structname> parameter.
      </para>
     </listitem>
    </varlistentry>
   </variablelist>

  </sect2>

 </sect1>

 <sect1 id="libpq-async">
  <title>Asynchronous Command Processing</title>

  <indexterm zone="libpq-async">
   <primary>nonblocking connection</primary>
  </indexterm>

  <para>
   The <xref linkend="libpq-PQexec"/> function is adequate for submitting
   commands in normal, synchronous applications.  It has a few
   deficiencies, however, that can be of importance to some users:

   <itemizedlist>
    <listitem>
     <para>
      <xref linkend="libpq-PQexec"/> waits for the command to be completed.
      The application might have other work to do (such as maintaining a
      user interface), in which case it won't want to block waiting for
      the response.
     </para>
    </listitem>

    <listitem>
     <para>
      Since the execution of the client application is suspended while it
      waits for the result, it is hard for the