class="parameter">level</replaceable> option specifies
    the error severity.  Allowed levels are <literal>DEBUG</literal>,
    <literal>LOG</literal>, <literal>INFO</literal>,
    <literal>NOTICE</literal>, <literal>WARNING</literal>,
    and <literal>EXCEPTION</literal>, with <literal>EXCEPTION</literal>
    being the default.
    <literal>EXCEPTION</literal> raises an error (which normally aborts the
    current transaction); the other levels only generate messages of different
    priority levels.
    Whether messages of a particular priority are reported to the client,
    written to the server log, or both is controlled by the
    <xref linkend="guc-log-min-messages"/> and
    <xref linkend="guc-client-min-messages"/> configuration
    variables. See <xref linkend="runtime-config"/> for more
    information.
   </para>

   <para>
    In the first syntax variant,
    after the <replaceable class="parameter">level</replaceable> if any,
    write a <replaceable class="parameter">format</replaceable> string
    (which must be a simple string literal, not an expression).  The
    format string specifies the error message text to be reported.
    The format string can be followed
    by optional argument expressions to be inserted into the message.
    Inside the format string, <literal>%</literal> is replaced by the
    string representation of the next optional argument's value. Write
    <literal>%%</literal> to emit a literal <literal>%</literal>.
    The number of arguments must match the number of <literal>%</literal>
    placeholders in the format string, or an error is raised during
    the compilation of the function.
   </para>

   <para>
    In this example, the value of <literal>v_job_id</literal> will replace the
    <literal>%</literal> in the string:
<programlisting>
RAISE NOTICE 'Calling cs_create_job(%)', v_job_id;
</programlisting>
   </para>

   <para>
    In the second and third syntax variants,
    <replaceable class="parameter">condition_name</replaceable> and
    <replaceable class="parameter">sqlstate</replaceable> specify an
    error condition name or a five-character SQLSTATE code, respectively.
    See <xref linkend="errcodes-appendix"/> for the valid error condition
    names and the predefined SQLSTATE codes.
   </para>

   <para>
    Here are examples
    of <replaceable class="parameter">condition_name</replaceable>
    and <replaceable class="parameter">sqlstate</replaceable> usage:
<programlisting>
RAISE division_by_zero;
RAISE WARNING SQLSTATE '22012';
</programlisting>
   </para>

   <para>
    In any of these syntax variants,
    you can attach additional information to the error report by writing
    <literal>USING</literal> followed by <replaceable
    class="parameter">option</replaceable> = <replaceable
    class="parameter">expression</replaceable> items.  Each
    <replaceable class="parameter">expression</replaceable> can be any
    string-valued expression.  The allowed <replaceable
    class="parameter">option</replaceable> key words are:

    <variablelist id="raise-using-options">
     <varlistentry id="raise-using-option-message">
      <term><literal>MESSAGE</literal></term>
      <listitem>
       <para>Sets the error message text.  This option can't be used in the
        first syntax variant, since the message is already supplied.</para>
      </listitem>
     </varlistentry>

     <varlistentry id="raise-using-option-detail">
      <term><literal>DETAIL</literal></term>
      <listitem>
       <para>Supplies an error detail message.</para>
      </listitem>
     </varlistentry>

     <varlistentry id="raise-using-option-hint">
      <term><literal>HINT</literal></term>
      <listitem>
       <para>Supplies a hint message.</para>
      </listitem>
     </varlistentry>

     <varlistentry id="raise-using-option-errcode">
      <term><literal>ERRCODE</literal></term>
      <listitem>
       <para>Specifies the error code (SQLSTATE) to report, either by condition
        name,