triggers
#
triggers
ビューには、現在のデータベース内で、現在のユーザが所有するあるいは何らかのSELECT
以外の権限を持つテーブルまたはビューに定義された、全てのトリガがあります。
表37.55 triggers
の列
列 型 説明 |
---|
トリガを持つデータベースの名前です(常に現在のデータベースです)。 |
トリガを持つスキーマの名前です。 |
トリガの名前です。 |
トリガを発するイベントです
( |
トリガが定義されたテーブルを持つデータベースの名前です(常に現在のデータベースです)。 |
トリガが定義されたテーブルを持つスキーマの名前です。 |
トリガが定義されたテーブルの名前です。 |
同じテーブルで同じ |
トリガの |
トリガによって実行される文です
(現在は常に |
トリガの発行が処理行ごとか文ごとかを識別します
( |
トリガを発する時期です
( |
「old」遷移テーブルの名前です。なければNULLです。 |
「new」遷移テーブルの名前です。なければNULLです。 |
PostgreSQLでは利用できない機能に適用されるものです。 |
PostgreSQLでは利用できない機能に適用されるものです。 |
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, event_object_table, trigger_name, event_manipulation)
となります。
それでもなお、標準SQLに従う(スキーマ内でトリガ名を一意とし、トリガに対し1種類のイベントしか持たせないという)手法でトリガを定義していれば、これは影響ありません。
PostgreSQL 9.1 より前は、このビューの列の
action_timing
、
action_reference_old_table
、
action_reference_new_table
、
action_reference_old_row
、
action_reference_new_row
はそれぞれ
condition_timing
、
condition_reference_old_table
、
condition_reference_new_table
、
condition_reference_old_row
、
condition_reference_new_row
という名前でした。これらの命名は SQL: 1999標準におけるものです。新しい名前はSQL:2003以降に準拠しています。