vulnerable to
       <quote>SQL injection</quote> attacks wherein unwanted SQL commands are
       fed to your database.
      </para>
     </tip>

     <para>
      Note that it is neither necessary nor correct to do escaping when a data
      value is passed as a separate parameter in <xref linkend="libpq-PQexecParams"/> or
      its sibling routines.
     </para>
     </listitem>
    </varlistentry>

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

     <listitem>
     <para>
<synopsis>
char *PQescapeIdentifier(PGconn *conn, const char *str, size_t length);
</synopsis>
     </para>

     <para>
      <xref linkend="libpq-PQescapeIdentifier"/> escapes a string for
      use as an SQL identifier, such as a table, column, or function name.
      This is useful when a user-supplied identifier might contain
      special characters that would otherwise not be interpreted as part
      of the identifier by the SQL parser, or when the identifier might
      contain upper case characters whose case should be preserved.
     </para>

     <para>
      <xref linkend="libpq-PQescapeIdentifier"/> returns a version of the
      <parameter>str</parameter> parameter escaped as an SQL identifier
      in memory allocated with <function>malloc()</function>.  This memory must be
      freed using <function>PQfreemem()</function> when the result is no longer
      needed.  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-PQescapeIdentifier"/> stops at the zero; the behavior is
      thus rather like <function>strncpy</function>.) The
      return string has all special characters replaced so that it
      will be properly processed as an SQL identifier.  A terminating zero byte
      is also added.  The return string will also be surrounded by double
      quotes.
     </para>

     <para>
      On error, <xref linkend="libpq-PQescapeIdentifier"/> returns <symbol>NULL</symbol> and a suitable
      message is stored in the <parameter>conn</parameter> object.
     </para>

     <tip>
      <para>
       As with string literals, to prevent SQL injection attacks,
       SQL identifiers must be escaped when they are received from an
       untrustworthy source.
      </para>
     </tip>
     </listitem>
    </varlistentry>

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

     <listitem>
     <para>
<synopsis>
size_t PQescapeStringConn(PGconn *conn,
                          char *to, const char *from, size_t length,
                          int *error);
</synopsis>
     </para>

     <para>
      <xref linkend="libpq-PQescapeStringConn"/> escapes 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