<listitem>
    <para>
     <function>errcode_for_file_access()</function> is a convenience function that
     selects an appropriate SQLSTATE error identifier for a failure in a
     file-access-related system call.  It uses the saved
     <literal>errno</literal> to determine which error code to generate.
     Usually this should be used in combination with <literal>%m</literal> in the
     primary error message text.
    </para>
   </listitem>
   <listitem>
    <para>
     <function>errcode_for_socket_access()</function> is a convenience function that
     selects an appropriate SQLSTATE error identifier for a failure in a
     socket-related system call.
    </para>
   </listitem>
   <listitem>
    <para>
     <function>errhidestmt(bool hide_stmt)</function> can be called to specify
     suppression of the <literal>STATEMENT:</literal> portion of a message in the
     postmaster log.  Generally this is appropriate if the message text
     includes the current statement already.
    </para>
   </listitem>
   <listitem>
    <para>
     <function>errhidecontext(bool hide_ctx)</function> can be called to
     specify suppression of the <literal>CONTEXT:</literal> portion of a message in
     the postmaster log.  This should only be used for verbose debugging
     messages where the repeated inclusion of context would bloat the log
     too much.
    </para>
   </listitem>
  </itemizedlist>
   </para>

   <note>
    <para>
     At most one of the functions <function>errtable</function>,
     <function>errtablecol</function>, <function>errtableconstraint</function>,
     <function>errdatatype</function>, or <function>errdomainconstraint</function> should
     be used in an <function>ereport</function> call.  These functions exist to
     allow applications to extract the name of a database object associated
     with the error condition without having to examine the
     potentially-localized error message text.
     These functions should be used in error reports for which it's likely
     that applications would wish to have automatic error handling.  As of
     <productname>PostgreSQL</productname> 9.3, complete coverage exists only for
     errors in SQLSTATE class 23 (integrity constraint violation), but this
     is likely to be expanded in future.
    </para>
   </note>

   <para>
    There is an older function <function>elog</function> that is still heavily used.
    An <function>elog</function> call:
<programlisting>
elog(level, "format string", ...);
</programlisting>
    is exactly equivalent to:
<programlisting>
ereport(level, errmsg_internal("format string", ...));
</programlisting>
    Notice that the SQLSTATE error code is always defaulted, and the message
    string is not subject to translation.
    Therefore, <function>elog</function> should be used only for internal errors and
    low-level debug logging.  Any message that is likely to be of interest to
    ordinary users should go through <function>ereport</function>.  Nonetheless,
    there are enough internal <quote>cannot happen</quote> error checks in the
    system that <function>elog</function> is still widely used; it is preferred for
    those messages for its notational simplicity.
   </para>

   <para>
    Advice about writing good error messages can be found in
    <xref linkend="error-style-guide"/>.
   </para>
  </sect1>

  <sect1 id="error-style-guide">
   <title>Error Message Style Guide</title>

   <para>
    This style guide is offered in the hope of maintaining a consistent,
    user-friendly style throughout all the messages generated by
    <productname>PostgreSQL</productname>.
   </para>

  <simplesect id="error-style-guide-what-goes-where">
   <title>What Goes Where</title>

   <para>
    The primary message should be short, factual, and avoid reference to
    implementation details such as specific function names.
    <quote>Short</quote> means <quote>should fit on one line under normal
    conditions</quote>.  Use a detail message if needed