triggersビューには、現在のデータベースで定義された、現在のユーザが所有する全てのトリガがあります。 (テーブルの所有者がトリガの所有者です。)
表 30-35. triggers の列
名前 | データ型 | 説明 |
---|---|---|
trigger_catalog | sql_identifier | トリガを持つデータベースの名前です。(常に現在のデータベースです。) |
trigger_schema | sql_identifier | トリガを持つスキーマの名前です。 |
trigger_name | sql_identifier | トリガの名前です。 |
event_manipulation | character_data | トリガを発するイベントです。 (INSERT、UPDATEもしくはDELETEです。) |
event_object_catalog | sql_identifier | トリガが定義されたテーブルを持つデータベースの名前です。 (常に現在のデータベースです。) |
event_object_schema | sql_identifier | トリガが定義されたテーブルを持つスキーマの名前です。 |
event_object_name | sql_identifier | トリガが定義されたテーブルの名前です。 |
action_order | cardinal_number | 未実装です。 |
action_condition | character_data | PostgreSQLで利用できない機能に適用されるものです。 |
action_statement | character_data | トリガによって実行される文です。 (現在は常にEXECUTE PROCEDURE function(...)です。) |
action_orientation | character_data | トリガの発行が処理行毎か文毎かを識別します。 (ROW もしくは STATEMENTです。) |
condition_timing | character_data | トリガを発する時期です。 (BEFORE もしくは AFTERです。) |
condition_reference_old_table | sql_identifier | PostgreSQLで利用できない機能に適用されるものです。 |
condition_reference_new_table | sql_identifier | PostgreSQLで利用できない機能に適用されるものです。 |
PostgreSQLにおけるトリガには、標準SQLと比べ、2つの非互換があり、これらは情報スキーマの表現に影響を与えます。 1つめは、PostgreSQLではトリガ名は、独立したスキーマオブジェクトではなく、テーブル内で局所的であることです。 そのため、別のテーブルに属している場合、1つのスキーマ内でトリガ名が重複する可能性があります。 (trigger_catalog と trigger_schema は実際、そのトリガが定義されたテーブルに属する値となります。) 2つめは、PostgreSQLではトリガは複数のイベントで発行できる点です。(例えばON INSERT OR UPDATEです。) 一方、標準SQLでは1つのみしか許されません。 トリガが複数のイベントで発行するように定義された場合、それぞれのイベントで1行という形で、情報スキーマ内では複数の行として表現されます。 これらの2つの問題の結果、triggersビューのプライマリキーは実際、標準SQLで定義された(trigger_catalog, trigger_schema, trigger_name)ではなく、(trigger_catalog, trigger_schema, trigger_name, event_object_name, event_manipulation) となります。 それでもなお、標準SQLに従う(スキーマ内でトリガ名を一意とし、トリガに対し1種類のイベントしかもたせないという)手法でトリガを定義していれば、これは影響ありません。