worth the security issues that this function has.
      </para>

      <para>
       The <structname>PGcancel</structname> object is read-only as far as
       <xref linkend="libpq-PQcancel"/> is concerned, so it can also be invoked
       from a thread that is separate from the one manipulating the
       <structname>PGconn</structname> object.
      </para>

      <para>
       The return value of <xref linkend="libpq-PQcancel"/> is 1 if the
       cancel request was successfully dispatched and 0 if not.
       If not, <parameter>errbuf</parameter> is filled with an explanatory
       error message.
       <parameter>errbuf</parameter> must be a char array of size
       <parameter>errbufsize</parameter> (the recommended size is 256 bytes).
      </para>
     </listitem>
    </varlistentry>
   </variablelist>

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

     <listitem>
      <para>
       <xref linkend="libpq-PQrequestCancel"/> is a deprecated and insecure
       variant of <xref linkend="libpq-PQcancelBlocking"/>.
<synopsis>
int PQrequestCancel(PGconn *conn);
</synopsis>
      </para>

      <para>
       <xref linkend="libpq-PQrequestCancel"/> only exists because of backwards
       compatibility reasons. <xref linkend="libpq-PQcancelBlocking"/> should be
       used instead. There is no benefit to using
       <xref linkend="libpq-PQrequestCancel"/> over
       <xref linkend="libpq-PQcancelBlocking"/>.
      </para>

      <para>
       Requests that the server abandon processing of the current
       command.  It operates directly on the
       <structname>PGconn</structname> object, and in case of failure stores the
       error message in the <structname>PGconn</structname> object (whence it can
       be retrieved by <xref linkend="libpq-PQerrorMessage"/>).  Although
       the functionality is the same, this approach is not safe within
       multiple-thread programs or signal handlers, since it is possible
       that overwriting the <structname>PGconn</structname>'s error message will
       mess up the operation currently in progress on the connection.
      </para>
     </listitem>
    </varlistentry>
   </variablelist>
  </sect2>
 </sect1>

 <sect1 id="libpq-fastpath">
  <title>The Fast-Path Interface</title>

  <indexterm zone="libpq-fastpath">
   <primary>fast path</primary>
  </indexterm>

  <para>
   <productname>PostgreSQL</productname> provides a fast-path interface
   to send simple function calls to the server.
  </para>

  <tip>
   <para>
    This interface is somewhat obsolete, as one can achieve similar
    performance and greater functionality by setting up a prepared
    statement to define the function call.  Then, executing the statement
    with binary transmission of parameters and results substitutes for a
    fast-path function call.
   </para>
  </tip>

  <para>
   The function <function id="libpq-PQfn">PQfn</function><indexterm><primary>PQfn</primary></indexterm>
   requests execution of a server function via the fast-path interface:
<synopsis>
PGresult *PQfn(PGconn *conn,
               int fnid,
               int *result_buf,
               int *result_len,
               int result_is_int,
               const PQArgBlock *args,
               int nargs);

typedef struct
{
    int len;
    int isint;
    union
    {
        int *ptr;
        int integer;
    } u;
} PQArgBlock;
</synopsis>
  </para>

  <para>
   The <parameter>fnid</parameter> argument is the OID of the function to be
   executed.  <parameter>args</parameter> and <parameter>nargs</parameter> define the
   parameters to be passed to the function; they must match the declared
   function argument list.  When the <parameter>isint</parameter> field of a
   parameter structure is true, the <parameter>u.integer</parameter> value is sent
   to the server as an integer of the indicated length (this must