RAISE文を使用してメッセージを報告し、エラーを発生することができます。
RAISE level 'format' [, variable [, ...]];使用可能なレベルは、DEBUG、LOG、INFO、NOTICE、WARNINGおよびEXCEPTIONです。 EXCEPTIONはエラーを発生させ、現在のトランザクションをアボートします。 他のレベルは異なる優先度レベルのメッセージを生成するだけです。 特定の優先度のエラーメッセージがクライアントに報告するか、サーバログに書き込むか、またはその両方は、log_min_messagesおよびclient_min_messages設定変数によって制御されます。 詳細については、項16.4を参照して下さい。
書式文字列内では、%は次の省略可能な引数の文字列表現で書き換えられます。 %%と記述することで%リテラルを表すことができます。 現在、省略可能な引数は単純な変数でなければならず、式を書くことはできません。 書式もまた、単純な文字列リテラルでなければなりません。
以下の例では、v_job_idの値は文字列内の%を置き換えます。
RAISE NOTICE ''Calling cs_create_job(%)'', v_job_id;
以下の例では、トランザクションを中断させ、指定されたエラーメッセージを表示します。
RAISE EXCEPTION ''Inexistent ID --> %'', user_id;
PostgreSQLの例外を扱う方式はあまり気の効いたものではありません。 パーサ、プランナ/オプティマイザ、またはエクゼキュータがこれ以上文を実行することがでいないと判断すると、トランザクション全体を中断し、システムはクライアントアプリケーションからの次のコマンドを受け付けるメインループに戻ります。
これが発生したことを通知するために、エラー機構に引っかけることができます。 しかし、現時点では、(データ型の書式エラー、浮動小数点エラー、解析エラーといったもののうち)何が実際にその中断を引き起こしたのかを通知することはできません。 そして、この段階ではバックエンドは不整合状態にあるので上位のエクゼキュータに戻したり、コマンドを更に発行するとデータベース全体を壊してしまうかもしれません。
従って、現段階で関数やトリガプロシージャ実行中に中断が起きた時に、PL/pgSQLができることは、どの関数のどこ(行番号と文の型)で発生したのか知らせるフィールドをいくつかメッセージに追加することだけです。 このエラーは常に関数の実行を停止します。