By
default, any error occurring in a PL/pgSQL function aborts execution of
the function, and indeed of the surrounding transaction as well. You
can trap errors and recover from them by using a BEGIN block with an
EXCEPTION clause. The syntax is an extension of the normal syntax for a
BEGIN block: [ <<label>> ] [ DECLARE declarations ] BEGIN statements EXCEPTION WHEN condition [ OR condition ... ] THEN handler_statements [ WHEN condition [ OR condition ... ] THEN handler_statements ... ] END; If no error occurs, this form of block simply executes all the statements, and then control passes to the next statement after END. But if an error occurs within the statements, further processing of the statements is abandoned, and control passes to the EXCEPTION list. The list is searched for the first condition matching the error that occurred. If a match is found, the corresponding handler_statements are executed, and then control passes to the next statement after END. If no match is found, the error propagates out as though the EXCEPTION clause were not there at all: the error can be caught by an enclosing block with EXCEPTION, or if there is none it aborts processing of the function. The
condition names can be any of those shown in Error Codes listed above. A
category name matches any error within its category. The special
condition name OTHERS matches every error type except QUERY_CANCELED.
(It is possible, but often unwise, to trap QUERY_CANCELED by name.)
Condition names are not case-sensitive. If
a new error occurs within the selected handler_statements, it cannot be
caught by this EXCEPTION clause, but is propagated out. A surrounding
EXCEPTION clause could catch it. When
an error is caught by an EXCEPTION clause, the local variables of the
PL/pgSQL function remain as they were when the error occurred, but all
changes to persistent database state within the block are rolled back. |
PostgreSQL Database >