他のバージョンの文書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

19.8. エラーとメッセージ

RAISE 文を使用してメッセージを報告し、エラーを発生することができます。

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

使用可能なレベルは、DEBUG (メッセージをサーバログに書き込む)、LOG (より高い優先順位でメッセージをサーバログに書き込む)、INFONOTICE および WARNING (それぞれより高い優先順位で、メッセージをサーバログに書き込み、そのメッセージをクライアントに送信する)、および EXCEPTION (エラーを発生させ、現在のトランザクションをアボートする) です。 特定の優先順位のエラーメッセージがクライアントに報告するか、サーバログに書き込むか、またはその両方は、SERVER_MIN_MESSAGES および CLIENT_MIN_MESSAGES 設定変数によって制御されます。 詳細については、PostgreSQL 管理者用ガイドを参照して下さい。

書式文字列内では、% は次の省略可能な引数の外部表現で書き換えられます。%% と記述することで % リテラルを表すことができます。現在、省略可能な引数は単純な変数でなければならず、式を書くことはできません。 書式もまた、単純な文字列リテラルでなければなりません。

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

この例では、v_job_id の値は文字列内の % を書き換えます。

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

これは指定したエラーメッセージをもって、トランザクションを中断します。

19.8.1. 例外

PostgreSQLの例外を扱う方式はあまり気の効いたものではありません。パーサ、プランナ、オプティマイザ、またはエクゼキュータがこれ以上文を実行することがでいないと判断すると、トランザクション全体を中断し、システムはクライアントアプリケーションからの次の問い合わせを受け付けるメインループに戻ります。

これが発生したことを通知するために、エラー機構に引っかけることができます。しかし、現時点では、(入出力変換エラー、浮動小数点エラー、分析エラーといったもののうち)何がその中断を引き起こしたのかを通知することはできません。そして、この段階ではバックエンドは不整合状態にあるので上位のエクゼキュータに戻したり、コマンドを更に発行するとデータベース全体を壊してしまうかもしれません。

従って、現段階で関数やトリガプロシージャ実行中に中断が起きたときに、PL/pgSQL ができることは、どの関数のどこ (行番号と文の型) で発生したのか知らせるといった追加的な NOTICE レベルのログメッセージを出力することのみです。このエラーは常に関数の実行を停止します。