トリガとルールの実行モデルと副作用順序

トリガが発火する3つのタイミング

トリガは、テーブルへの INSERT/UPDATE/DELETE をきっかけに自動実行される手続きです。問題は「いつ呼ばれるか」で、これは3種のタイミングで定義されます。

• BEFORE: 実際の行操作が起きる前に発火する。ここで NEW（挿入・更新後の行イメージ）を書き換えると、その書き換えがそのまま実テーブルに反映される。値の補正・バリデーション・既定値の動的計算に使う。
• AFTER: 行操作が完了した後に発火する。NEW/OLD は読めるが書き換えても無視される。確定済みのデータを前提とした派生処理（監査ログ記録、集計テーブル更新、別テーブルへの伝播）に使う。
• INSTEAD OF: 主にビューに対して定義し、本来の操作を置き換える。ビューは実体を持たないので、INSERT などをそのまま適用できない。代わりに INSTEAD OF トリガが「実テーブルへどう書くか」を肩代わりする。

行レベルと文レベル：発火回数が違う

トリガには発火の粒度が2つあり、回数と参照できる情報が変わります。

1000行を1文で更新すると、行レベルトリガは1000回、文レベルトリガは1回呼ばれます。文レベルでも個々の変更行をまとめて扱いたい場合は、遷移テーブル（REFERENCING ... OLD/NEW TABLE）で変更行の集合を1つのリレーションとして受け取れます。これにより「1文ぶんの差分」に対して集合演算（→ マテリアライズドビュー の差分更新など）を1回で適用でき、行ごと発火より効率的です。

発火の全体順序は次の通りで、BEFORE が本体を挟み込む構造になっています。

BEFORE 文トリガ
  └ 各影響行について:
       BEFORE 行トリガ（NEW を書き換え可能 / NULL でスキップ）
       実際の行操作（テーブルへの書き込み・制約チェック）
       AFTER 行トリガ（確定値を参照、書き換え不可）
AFTER 文トリガ

同タイミングのトリガが複数あるときの順序

同じテーブル・同じタイミング（例: BEFORE UPDATE 行レベル）に複数のトリガが定義されていると、その相互の発火順が問題になります。ここは標準と実装で扱いが分かれます。

• SQL 標準: 同一タイミングのトリガは作成時刻順に発火すると規定。
• PostgreSQL: **トリガ名の昇順（アルファベット順）**で発火する。順序を制御したいなら 01_validate、02_audit のように名前で並びを設計するのが定石。
• Oracle / SQL Server: 明示指定がなければ順序は未定義に近く、Oracle は FOLLOWS/PRECEDES、SQL Server は sp_settriggerorder で順序を限定的に制御する。

なお、AFTER トリガの実行は「文の完了時点」あるいは「トランザクションのコミット時点（DEFERRED 制約トリガ）」までキューに積まれて遅延されることがあります。外部キー制約は内部的に AFTER トリガとして実装されており、この遅延キューに乗ります。AFTER 行トリガが大量にキューされるとメモリを圧迫する点も実務上の注意点です。

再帰トリガ：トリガが次のトリガを呼ぶ

トリガ本体が SQL を実行し、その SQL がまた別のトリガ（あるいは自分自身）を発火させる連鎖を再帰トリガと呼びます。これは強力ですが、停止性が保証されません。

-- 親カテゴリの更新が子へ伝播し、子の更新がさらに孫へ…と連鎖
CREATE FUNCTION cascade_flag() RETURNS trigger AS $$
BEGIN
  UPDATE node SET flag = NEW.flag
  WHERE parent_id = NEW.id AND flag <> NEW.flag;  -- 終了条件が要
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

上の例で flag <> NEW.flag という終了条件を外すと、同じ行を何度も更新し続けて無限ループに陥ります。再帰の深さには実装上の上限（PostgreSQL の max_stack_depth 由来のスタック制限など）があり、超えるとエラーで全体がロールバックします。

SQL Server には RECURSIVE_TRIGGERS というデータベース設定があり、直接再帰（トリガが同じテーブルを更新して自分を再発火）をオフにできます。PostgreSQL にこの大域スイッチはなく、終了条件で自衛するのが基本方針です。トリガとトランザクションの関係上、連鎖の途中で例外が出れば（→ トランザクションの基礎）その文（またはトランザクション）全体が巻き戻ります。

ルールシステム：実行前に問い合わせを書き換える

PostgreSQL 固有のルールシステム（CREATE RULE）は、トリガと混同されがちですが作用する層がまったく異なります。トリガが実行時に行ごと・文ごとに手続きを走らせるのに対し、ルールは問い合わせの計画前に、入力された問い合わせツリー（パースツリー）を別のツリーへ書き換える仕組みです。これを問い合わせ書き換え（query rewriting）と呼びます。

最も身近な例がビューです。CREATE VIEW は内部的に、ビューへの SELECT を元テーブルへの SELECT に置換する ON SELECT ルールとして実装されています。更新可能ビューも、ON INSERT/ON UPDATE/ON DELETE ルール（または前述の INSTEAD OF トリガ）で実テーブルへの操作に書き換わります。

ルールの意味論で躓きやすいのが「副作用の重複」です。DO INSTEAD でない条件付きルールは、元の問い合わせとルールが生成した問い合わせの両方を実行します。さらに、ルール本体の中で NEW や OLD を参照する式が複数回現れると、その参照ぶん副問い合わせが展開され、揮発性関数（nextval など連番採番）が想定より多く評価されることがあります。これがルールが「危険」と言われる典型例です。

まとめ

• 発火順序は BEFORE →（本体操作）→ AFTER。値を確定・改変できるのは BEFORE 行トリガだけで、AFTER は確定後の値にしか反応できない。INSTEAD OF はビューへの操作を実テーブルへ肩代わりする。
• 行レベルは影響行ごと、文レベルは1文1回。同タイミングの複数トリガの順は実装依存（PostgreSQL は名前昇順）で、順序前提の設計は避ける。遷移テーブルで差分集合を1回で扱える。
• 再帰トリガは終了条件と収束性をセットで設計し、無限再帰とスタック超過を防ぐ。AFTER の遅延キューと例外時の巻き戻りも織り込む。
• ルールシステムは計画前のツリー書き換えで、トリガとは層が違う。副作用の重複や揮発性関数の多重評価という罠があるため、ビュー定義以外は手続きが直感的なトリガ（→ ストアドプロシージャ）や、MVCC 下での可視性（→ MVCC の内部実装）も踏まえて選ぶのが安全。