Supported Versions: Current (16) / 15 / 14 / 13 / 12
Development Versions: devel
Unsupported versions: 11 / 10 / 9.6 / 9.5 / 9.4 / 9.3 / 9.2 / 9.1 / 9.0 / 8.4 / 8.3 / 8.2 / 8.1 / 8.0 / 7.4 / 7.3 / 7.2
This documentation is for an unsupported version of PostgreSQL.
You may want to view the same page for the current version, or one of the other supported versions listed above instead.

19.8. Errors and Messages

Use the RAISE statement to report messages and raise errors.

RAISE level 'format' [, variable [...]];

Possible levels are DEBUG (write the message to the server log), LOG (write the message to the server log with a higher priority), INFO, NOTICE and WARNING (write the message to the server log and send it to the client, with respectively higher priorities), and EXCEPTION (raise an error and abort the current transaction). Whether error messages of a particular priority are reported to the client, written to the server log, or both is controlled by the SERVER_MIN_MESSAGES and CLIENT_MIN_MESSAGES configuration variables. See the PostgreSQL Administrator's Guide for more information.

Inside the format string, % is replaced by the next optional argument's external representation. Write %% to emit a literal %. Note that the optional arguments must presently be simple variables, not expressions, and the format must be a simple string literal.

Examples:

RAISE NOTICE ''Calling cs_create_job(%)'',v_job_id;

In this example, the value of v_job_id will replace the % in the string.

RAISE EXCEPTION ''Inexistent ID --> %'',user_id;

This will abort the transaction with the given error message.

19.8.1. Exceptions

PostgreSQL does not have a very smart exception handling model. Whenever the parser, planner/optimizer or executor decide that a statement cannot be processed any longer, the whole transaction gets aborted and the system jumps back into the main loop to get the next query from the client application.

It is possible to hook into the error mechanism to notice that this happens. But currently it is impossible to tell what really caused the abort (input/output conversion error, floating-point error, parse error). And it is possible that the database backend is in an inconsistent state at this point so returning to the upper executor or issuing more commands might corrupt the whole database.

Thus, the only thing PL/pgSQL currently does when it encounters an abort during execution of a function or trigger procedure is to write some additional NOTICE level log messages telling in which function and where (line number and type of statement) this happened. The error always stops execution of the function.