Use the RAISE statement to report messages and
    raise errors.
RAISE [level] 'format' [,expression[, ... ]] [ USINGoption=expression[, ... ] ]; RAISE [level]condition_name[ USINGoption=expression[, ... ] ]; RAISE [level] SQLSTATE 'sqlstate' [ USINGoption=expression[, ... ] ]; RAISE [level] USINGoption=expression[, ... ]; RAISE ;
    The level option specifies
    the error severity.  Allowed levels are DEBUG,
    LOG, INFO,
    NOTICE, WARNING,
    and EXCEPTION, with EXCEPTION
    being the default.
    EXCEPTION 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
    log_min_messages and
    client_min_messages configuration
    variables. See Chapter 19 for more
    information.
   
    After level if any,
    you can specify a format 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, % is replaced by the
    string representation of the next optional argument's value. Write
    %% to emit a literal %.
    The number of arguments must match the number of %
    placeholders in the format string, or an error is raised during
    the compilation of the function.
   
    In this example, the value of v_job_id will replace the
    % in the string:
RAISE NOTICE 'Calling cs_create_job(%)', v_job_id;
    You can attach additional information to the error report by writing
    USING followed by option = expression items.  Each
    expression can be any
    string-valued expression.  The allowed option key words are:
    
MESSAGESets the error message text.  This option can't be used in the
        form of RAISE that includes a format string
        before USING.
DETAILSupplies an error detail message.
HINTSupplies a hint message.
ERRCODESpecifies the error code (SQLSTATE) to report, either by condition name, as shown in Appendix A, or directly as a five-character SQLSTATE code.
COLUMNCONSTRAINTDATATYPETABLESCHEMASupplies the name of a related object.
This example will abort the transaction with the given error message and hint:
RAISE EXCEPTION 'Nonexistent ID --> %', user_id
      USING HINT = 'Please check your user ID';
These two examples show equivalent ways of setting the SQLSTATE:
RAISE 'Duplicate user ID: %', user_id USING ERRCODE = 'unique_violation'; RAISE 'Duplicate user ID: %', user_id USING ERRCODE = '23505';
    There is a second RAISE syntax in which the main argument
    is the condition name or SQLSTATE to be reported, for example:
RAISE division_by_zero; RAISE SQLSTATE '22012';
    In this syntax, USING can be used to supply a custom
    error message, detail, or hint.  Another way to do the earlier
    example is
RAISE unique_violation USING MESSAGE = 'Duplicate user ID: ' || user_id;
    Still another variant is to write RAISE USING or RAISE
     and put
    everything else into the level USINGUSING list.
   
    The last variant of RAISE has no parameters at all.
    This form can only be used inside a BEGIN block's
    EXCEPTION clause;
    it causes the error currently being handled to be re-thrown.
   
     Before PostgreSQL 9.1, RAISE without
     parameters was interpreted as re-throwing the error from the block
     containing the active exception handler.  Thus an EXCEPTION
     clause nested within that handler could not catch it, even if the
     RAISE was within the nested EXCEPTION clause's
     block. This was deemed surprising as well as being incompatible with
     Oracle's PL/SQL.
    
    If no condition name nor SQLSTATE is specified in a
    RAISE EXCEPTION command, the default is to use
    ERRCODE_RAISE_EXCEPTION (P0001).
    If no message text is specified, the default is to use the condition
    name or SQLSTATE as message text.
   
     When specifying an error code by SQLSTATE code, you are not
     limited to the predefined error codes, but can select any
     error code consisting of five digits and/or upper-case ASCII
     letters, other than 00000.  It is recommended that
     you avoid throwing error codes that end in three zeroes, because
     these are category codes and can only be trapped by trapping
     the whole category.
    
    The ASSERT statement is a convenient shorthand for
    inserting debugging checks into PL/pgSQL
    functions.
ASSERTcondition[ ,message];
    The condition is a Boolean
    expression that is expected to always evaluate to true; if it does,
    the ASSERT statement does nothing further.  If the
    result is false or null, then an ASSERT_FAILURE exception
    is raised.  (If an error occurs while evaluating
    the condition, it is
    reported as a normal error.)
   
    If the optional message is
    provided, it is an expression whose result (if not null) replaces the
    default error message text “assertion failed”, should
    the condition fail.
    The message expression is
    not evaluated in the normal case where the assertion succeeds.
   
    Testing of assertions can be enabled or disabled via the configuration
    parameter plpgsql.check_asserts, which takes a Boolean
    value; the default is on.  If this parameter
    is off then ASSERT statements do nothing.
   
    Note that ASSERT is meant for detecting program
    bugs, not for reporting ordinary error conditions.  Use
    the RAISE statement, described above, for that.