多くの場合トリガにはユーザ記述のトリガ関数が必要になりますが、PostgreSQLはユーザ定義トリガで直接使用できる小数の組み込みの取り化関数を提供しています。 これらは表 9.103にまとめられています。 （追加の組み込みトリガ関数があり、外部キー制約と遅延インデックス制約を実装しています。 ユーザがこれらを直接必要とすることはないので、ここには記述されていません。）
トリガ作成についてより詳細はCREATE TRIGGERを参照ください。
表9.103 組み込みトリガ関数
関数 説明 使用例 |
|---|
do-nothing更新操作を抑止します。 詳細は以下を参照してください。
|
関連付けされた平文文書列から自動的に
|
関連付けされた平文文書列から自動的に
|
行レベルBEFORE UPDATEトリガとしてsuppress_redundant_updates_trigger関数が適用されると、実際には行の中でデータを変更しない更新が行われるのを防ぎます。
これはデータが変更されるかどうかに関わらず、物理的に行の更新を行う通常の振る舞いを置き換えます。
（この通常の動作は、検査を必要としないため更新をより迅速に行い、場合によっては便利です。）
理想的には、通常実際レコード内のデータを変更しない更新の実行を避けるべきです。
冗長な更新により、特に変更対象の多くのインデックスが存在する場合、無視できない不要な時間にかかるコストが発生することがあります。
また、最後にはバキュームしなければならなくなる不要行が場所を取ることになります。
しかし、こうした状況をクライアント側で判定することは常に簡単ではありません。
また、可能であったとしても、それを検知するための式の記述はエラーを招きがちです。
他の方法として、suppress_redundant_updates_triggerを使用することがあります。
これはデータを変更しない更新をスキップします。
しかしこの関数は注意して使用しなければなりません。
このトリガはレコードごとに小さな、しかし僅かではない時間がかかります。
このため、更新が影響するレコードのほとんどが実際に変更された場合、このトリガは平均すると更新の実行を低速にします。
suppress_redundant_updates_trigger関数は以下のようにテーブルに追加できます。
CREATE TRIGGER z_min_update BEFORE UPDATE ON tablename FOR EACH ROW EXECUTE FUNCTION suppress_redundant_updates_trigger();
ほとんどの場合、行を変更するかも知れない他のトリガを置き換えないために、それぞれの行に対しこのトリガを最後に起動させる必要があります。 トリガは名前順に起動されることを判っているとして、テーブル上に存在する可能性のある他のトリガの名前の後に続くようトリガ名を選択できます。 （それで例中に「z」接頭辞があります。）