A trigger is a specification that the database should automatically execute a particular function whenever a certain type of operation is performed. Triggers can be attached to tables (partitioned or not), views, and foreign tables. トリガとは、データベースが、ある特定の操作が行われた時に常に自動的に実行しなければならない特定の機能に関する規定です。 トリガはテーブル（パーティション化されているかどうかにかかわらず）、ビュー、外部テーブルに付与することができます。

On tables and foreign tables, triggers can be defined to execute either before or after any <command>INSERT</command>, <command>UPDATE</command>, or <command>DELETE</command> operation, either once per modified row, or once per <acronym>SQL</acronym> statement. <command>UPDATE</command> triggers can moreover be set to fire only if certain columns are mentioned in the <literal>SET</literal> clause of the <command>UPDATE</command> statement. Triggers can also fire for <command>TRUNCATE</command> statements. If a trigger event occurs, the trigger's function is called at the appropriate time to handle the event. テーブルおよび外部テーブル上では、トリガをINSERT、UPDATEまたはDELETE操作の前後に、行を変更する度、あるいはSQL文ごとに実行するように定義することができます。 さらに、UPDATEトリガについては、特定のカラムがUPDATE文のSET句の対象になった時のみ発動するよう設定することができます。 また、トリガはTRUNCATE文についても発動できます。 トリガイベントが起こると、トリガ関数がそのイベントを扱う適切な時点で呼び出されます。

On views, triggers can be defined to execute instead of <command>INSERT</command>, <command>UPDATE</command>, or <command>DELETE</command> operations. Such <literal>INSTEAD OF</literal> triggers are fired once for each row that needs to be modified in the view. It is the responsibility of the trigger's function to perform the necessary modifications to the view's underlying base table(s) and, where appropriate, return the modified row as it will appear in the view. Triggers on views can also be defined to execute once per <acronym>SQL</acronym> statement, before or after <command>INSERT</command>, <command>UPDATE</command>, or <command>DELETE</command> operations. However, such triggers are fired only if there is also an <literal>INSTEAD OF</literal> trigger on the view. Otherwise, any statement targeting the view must be rewritten into a statement affecting its underlying base table(s), and then the triggers that will be fired are the ones attached to the base table(s). ビュー上では、トリガをINSERT、UPDATEまたはDELETE操作の代わりに実行するものとして定義できます。 そうしたINSTEAD OFトリガは、ビュー内の変更を行うために必要となる行それぞれに対して一度発行されます。 ビューの元になっている基底テーブルへの必要な変更の実施、そして必要に応じて、ビュー上で見えるであろう変更された行を返却するのは、トリガ関数の責任です。 ビューへのトリガは、SQL文ごとに、INSERT、UPDATEまたはDELETE操作の前後で実行させるよう定義することもできます。 しかし、そうしたトリガは、ビューにINSTEAD OFトリガがあるときにだけ発行されます。 INSTEAD OFトリガを定義しない場合は、ビューを操作しようとする文は、元になる基底テーブルに影響を与える文に書き換えなければなりません。 その結果、発行されるトリガは、基底テーブルに付けられたトリガとなります。

The trigger function must be defined before the trigger itself can be created. The trigger function must be declared as a function taking no arguments and returning type <literal>trigger</literal>. (The trigger function receives its input through a specially-passed <structname>TriggerData</structname> structure, not in the form of ordinary function arguments.) トリガ関数は、トリガ自体が作成される前までに定義しておく必要があります。 トリガ関数は、引数を取らない、trigger型を返す関数として宣言される必要があります （トリガ関数は、通常の関数で使用される引数という形ではなく、TriggerData構造体で入力を受け取ります）。

Once a suitable trigger function has been created, the trigger is established with <xref linkend="sql-createtrigger"/>. The same trigger function can be used for multiple triggers. 適切なトリガ関数が作成されると、CREATE TRIGGERを使用してトリガを構築することができます。 同一のトリガ関数を複数のトリガに使用することができます。

<productname>PostgreSQL</productname> offers both <firstterm>per-row</firstterm> triggers and <firstterm>per-statement</firstterm> triggers. With a per-row trigger, the trigger function is invoked once for each row that is affected by the statement that fired the trigger. In contrast, a per-statement trigger is invoked only once when an appropriate statement is executed, regardless of the number of rows affected by that statement. In particular, a statement that affects zero rows will still result in the execution of any applicable per-statement triggers. These two types of triggers are sometimes called <firstterm>row-level</firstterm> triggers and <firstterm>statement-level</firstterm> triggers, respectively. Triggers on <command>TRUNCATE</command> may only be defined at statement level, not per-row. PostgreSQLは、行単位のトリガと文単位のトリガの両方を提供します。 行単位のトリガでは、トリガを発行した文によって影響を受ける行ごとにトリガ関数が呼び出されます。 反対に、文単位のトリガでは、適切な文が実行された時に、その文で何行が影響を受けたかどうかは関係なく、一度だけ呼び出されます。 特に、行に影響を与えない文であっても、適切な文単位のトリガがあれば実行されます。 この2種類のトリガはそれぞれ行レベルトリガと文レベルトリガと呼ばれることがあります。 TRUNCATEに対するトリガは、行単位ではなく、文レベルにのみに定義することができます。

Triggers are also classified according to whether they fire <firstterm>before</firstterm>, <firstterm>after</firstterm>, or <firstterm>instead of</firstterm> the operation. These are referred to as <literal>BEFORE</literal> triggers, <literal>AFTER</literal> triggers, and <literal>INSTEAD OF</literal> triggers respectively. Statement-level <literal>BEFORE</literal> triggers naturally fire before the statement starts to do anything, while statement-level <literal>AFTER</literal> triggers fire at the very end of the statement. These types of triggers may be defined on tables, views, or foreign tables. Row-level <literal>BEFORE</literal> triggers fire immediately before a particular row is operated on, while row-level <literal>AFTER</literal> triggers fire at the end of the statement (but before any statement-level <literal>AFTER</literal> triggers). These types of triggers may only be defined on tables and foreign tables, not views. <literal>INSTEAD OF</literal> triggers may only be defined on views, and only at row level; they fire immediately as each row in the view is identified as needing to be operated on. また、トリガはそれらが操作の前、後または代わりのどれで実行されるかに応じて分けられます。 これらはそれぞれBEFOREトリガ、AFTERトリガ、そしてINSTEAD OFトリガと呼ばれます。 文レベルのBEFOREトリガは、もちろん文が何かを始める前に発行され、文レベルのAFTERトリガは文の本当に最後に発行されます。 これらのタイプのトリガはテーブル、ビュー、あるいは外部テーブルに定義できます。 行レベルのBEFOREトリガは、特定の行が操作される直前に発行され、行レベルのAFTERトリガは文の終わり（ただし、全ての文レベルのAFTERトリガの前）に発行されます。 これらのタイプのトリガは、外部テーブルに定義できますが、ビューには定義できません。 INSTEAD OFトリガはビューにのみ定義され、行レベルのみが許されます。 つまり、ビュー上のそれぞれの行で処理が必要と判断された場合には、即座に発動します。

The execution of an <literal>AFTER</literal> trigger can be deferred to the end of the transaction, rather than the end of the statement, if it was defined as a <firstterm>constraint trigger</firstterm>. In all cases, a trigger is executed as part of the same transaction as the statement that triggered it, so if either the statement or the trigger causes an error, the effects of both will be rolled back. 制約トリガとして定義されている場合、AFTERトリガの実行は、トリガ実行を文の終わりではなく、トランザクションの終わりまで保留することができます。 すべての場合において、トリガはトリガが引き金となった文と同じトランザクションの一部として実行されるため、文またはトリガのいずれかがエラーを引き起こした場合、両方の結果がロールバックされます。

A statement that targets a parent table in an inheritance or partitioning hierarchy does not cause the statement-level triggers of affected child tables to be fired; only the parent table's statement-level triggers are fired. However, row-level triggers of any affected child tables will be fired. 継承あるいはパーティショニング階層において、親テーブルをターゲットとする文は、影響を受けた子テーブルの文レベルトリガを発動しません。 すなわち、親テーブルの文レベルトリガのみが発動します。 しかし、影響を受けた子テーブルの行レベルトリガは発動します。

If an <command>INSERT</command> contains an <literal>ON CONFLICT DO UPDATE</literal> clause, it is possible that the effects of row-level <literal>BEFORE</literal> <command>INSERT</command> triggers and row-level <literal>BEFORE</literal> <command>UPDATE</command> triggers can both be applied in a way that is apparent from the final state of the updated row, if an <varname>EXCLUDED</varname> column is referenced. There need not be an <varname>EXCLUDED</varname> column reference for both sets of row-level <literal>BEFORE</literal> triggers to execute, though. The possibility of surprising outcomes should be considered when there are both <literal>BEFORE</literal> <command>INSERT</command> and <literal>BEFORE</literal> <command>UPDATE</command> row-level triggers that change a row being inserted/updated (this can be problematic even if the modifications are more or less equivalent, if they're not also idempotent). Note that statement-level <command>UPDATE</command> triggers are executed when <literal>ON CONFLICT DO UPDATE</literal> is specified, regardless of whether or not any rows were affected by the <command>UPDATE</command> (and regardless of whether the alternative <command>UPDATE</command> path was ever taken). An <command>INSERT</command> with an <literal>ON CONFLICT DO UPDATE</literal> clause will execute statement-level <literal>BEFORE</literal> <command>INSERT</command> triggers first, then statement-level <literal>BEFORE</literal> <command>UPDATE</command> triggers, followed by statement-level <literal>AFTER</literal> <command>UPDATE</command> triggers and finally statement-level <literal>AFTER</literal> <command>INSERT</command> triggers. INSERTがON CONFLICT DO UPDATE句を含む場合、EXCLUDED列が参照されていると、行レベルのBEFORE INSERTトリガおよび行レベルのBEFORE UPDATEトリガの両方の効果が適用され、それが更新後の行の最後の状態から明らかな場合がありえます。 ただし、両方の行レベルのBEFOREトリガを実行するためにEXCLUDEDの参照が必要なわけではありません。 驚くような結果の可能性について、BEFORE INSERTとBEFORE UPDATEの両方の行レベルのトリガがあり、それらがいずれも挿入あるいは更新対象の行に影響を与える場合に考慮すべきです（これは更新が冪等ではないが、ほぼ同等であるときには、それでも問題になります）。 文レベルのUPDATEトリガはON CONFLICT DO UPDATEが指定されたとき、そのUPDATEによって行が影響を受けたかどうかに関わらず（そしてその代替であるUPDATE部分が実行されたかどうかに関わらず）実行されることに注意してください。 ON CONFLICT DO UPDATE句のあるINSERTでは、まず文レベルのBEFORE INSERTトリガ、次に文レベルのBEFORE UPDATEトリガ、次いで文レベルのAFTER UPDATEトリガ、最後に文レベルのAFTER INSERTトリガを実行します。

If an <command>UPDATE</command> on a partitioned table causes a row to move to another partition, it will be performed as a <command>DELETE</command> from the original partition followed by an <command>INSERT</command> into the new partition. In this case, all row-level <literal>BEFORE</literal> <command>UPDATE</command> triggers and all row-level <literal>BEFORE</literal> <command>DELETE</command> triggers are fired on the original partition. Then all row-level <literal>BEFORE</literal> <command>INSERT</command> triggers are fired on the destination partition. The possibility of surprising outcomes should be considered when all these triggers affect the row being moved. As far as <literal>AFTER ROW</literal> triggers are concerned, <literal>AFTER</literal> <command>DELETE</command> and <literal>AFTER</literal> <command>INSERT</command> triggers are applied; but <literal>AFTER</literal> <command>UPDATE</command> triggers are not applied because the <command>UPDATE</command> has been converted to a <command>DELETE</command> and an <command>INSERT</command>. As far as statement-level triggers are concerned, none of the <command>DELETE</command> or <command>INSERT</command> triggers are fired, even if row movement occurs; only the <command>UPDATE</command> triggers defined on the target table used in the <command>UPDATE</command> statement will be fired. あるパーティション化されたテーブルに適用されたUPDATEの結果、行が他のパーティションに移動することになるなら、元のパーティションでDELETEし、続いて新しいパーティションにINSERTする操作として実行されます。 この場合、すべての行レベルBEFORE UPDATEトリガとBEFORE DELETEトリガが元のパーティションで発動します。 そして、すべての行レベルBEFORE INSERTトリガが移動先のパーティションで発動します。 これらのトリガが移動対象の行に対して影響を及ぼす際に、驚くべき結果となる可能性を考慮しておくべきでしょう。 AFTER ROWトリガに関しては、AFTER DELETEとAFTER INSERTトリガが適用されます。しかし、AFTER UPDATEトリガは適用されません。なぜなら、UPDATEはDELETEとINSERTに変換されるからです。 文レベルのトリガに関しては、たとえ行の移動が起こったとしてもDELETEトリガもINSERTトリガも発動されません。UPDATE文中に現れた対象テーブルに定義されたUPDATEトリガだけが発動されます。

No separate triggers are defined for <command>MERGE</command>. Instead, statement-level or row-level <command>UPDATE</command>, <command>DELETE</command>, and <command>INSERT</command> triggers are fired depending on (for statement-level triggers) what actions are specified in the <command>MERGE</command> query and (for row-level triggers) what actions are performed. MERGEには個別のトリガは定義されません。 かわりに、文レベルまたは行レベルのUPDATE、DELETEおよびINSERTトリガが、MERGE問い合わせで指定されたアクション(文レベルトリガの場合)および実行されたアクション(行レベルトリガの場合)に応じて起動されます。

While running a <command>MERGE</command> command, statement-level <literal>BEFORE</literal> and <literal>AFTER</literal> triggers are fired for events specified in the actions of the <command>MERGE</command> command, irrespective of whether or not the action is ultimately performed. This is the same as an <command>UPDATE</command> statement that updates no rows, yet statement-level triggers are fired. The row-level triggers are fired only when a row is actually updated, inserted or deleted. So it's perfectly legal that while statement-level triggers are fired for certain types of action, no row-level triggers are fired for the same kind of action. MERGEコマンドの実行中、文レベルのBEFOREおよびAFTERトリガは、アクションが最終的に実行されるかどうかに関係なく、MERGEコマンドのアクションで指定されたイベントに対して発行されます。 これは、行を更新しないUPDATE文と同じですが、文レベルのトリガは発行されます。 行レベルのトリガは、行が実際に更新、挿入または削除されたときにのみ発行されます。 したがって、文レベルのトリガが特定のタイプのアクションに対して発行されるものの、同じ種類のアクションに対して行レベルのトリガが発行されないことは完全に合法です。

Trigger functions invoked by per-statement triggers should always return <symbol>NULL</symbol>. Trigger functions invoked by per-row triggers can return a table row (a value of type <structname>HeapTuple</structname>) to the calling executor, if they choose. A row-level trigger fired before an operation has the following choices: 文単位のトリガによって呼び出されるトリガ関数は常にNULLを返さなければなりません。 行単位のトリガによって呼び出されるトリガ関数は呼び出し元のエグゼキュータにテーブル行（HeapTuple型の値）を返すように選択することができます。 操作前に発行された行レベルのトリガでは以下の選択肢があります。

A row-level <literal>BEFORE</literal> trigger that does not intend to cause either of these behaviors must be careful to return as its result the same row that was passed in (that is, the <varname>NEW</varname> row for <command>INSERT</command> and <command>UPDATE</command> triggers, the <varname>OLD</varname> row for <command>DELETE</command> triggers). これらの動作をさせたくない行レベルのBEFOREトリガについては、渡された行（つまり、INSERTおよびUPDATEトリガではNEW行、DELETEの場合はOLD行）と同じ行結果を返すように気を付ける必要があります。

A row-level <literal>INSTEAD OF</literal> trigger should either return <symbol>NULL</symbol> to indicate that it did not modify any data from the view's underlying base tables, or it should return the view row that was passed in (the <varname>NEW</varname> row for <command>INSERT</command> and <command>UPDATE</command> operations, or the <varname>OLD</varname> row for <command>DELETE</command> operations). A nonnull return value is used to signal that the trigger performed the necessary data modifications in the view. This will cause the count of the number of rows affected by the command to be incremented. For <command>INSERT</command> and <command>UPDATE</command> operations only, the trigger may modify the <varname>NEW</varname> row before returning it. This will change the data returned by <command>INSERT RETURNING</command> or <command>UPDATE RETURNING</command>, and is useful when the view will not show exactly the same data that was provided. 行レベルのINSTEAD OFトリガは、ビューの元となった元テーブルのデータをまったく変更しないことを表すNULL、または、渡されたビューの行（INSERTとUPDATE操作の場合NEW行、DELETE操作の場合OLD行）を返さなければなりません。 非NULLの戻り値は、そのトリガがビューにおいて必要なデータ変更を実行したことを通知するために使用されます。 これにより影響を受けた行数を数えるカウンタは増加されます。 INSERTとUPDATE操作のみ、トリガは戻す前にNEW行を変更することができます。 これはINSERT RETURNINGまたはUPDATE RETURNINGで返されるデータを変更しますので、ビューが提供されたデータと正確に同じ結果を返さない場合に有益です。

The return value is ignored for row-level triggers fired after an operation, and so they can return <symbol>NULL</symbol>. 操作の後に発生する行レベルトリガでは戻り値は無視されますので、これらはNULLを返すことができます。

Some considerations apply for generated columns.<indexterm><primary>generated column</primary><secondary>in triggers</secondary></indexterm> Stored generated columns are computed after <literal>BEFORE</literal> triggers and before <literal>AFTER</literal> triggers. Therefore, the generated value can be inspected in <literal>AFTER</literal> triggers. In <literal>BEFORE</literal> triggers, the <literal>OLD</literal> row contains the old generated value, as one would expect, but the <literal>NEW</literal> row does not yet contain the new generated value and should not be accessed. In the C language interface, the content of the column is undefined at this point; a higher-level programming language should prevent access to a stored generated column in the <literal>NEW</literal> row in a <literal>BEFORE</literal> trigger. Changes to the value of a generated column in a <literal>BEFORE</literal> trigger are ignored and will be overwritten. 生成列に対してはいくつか考慮が必要です。 格納された生成列は、BEFOREトリガの後、AFTERトリガの前に計算されます。 そのため、生成される値はAFTERトリガで調べることができます。 BEFOREトリガでは、皆さんが期待している通りOLD行は以前の生成された値を含んでいますが、NEW行は新しく生成される値をまだ含んでおらず、アクセスすべきではありません。 C言語インタフェースでは、この時点では列の内容は未定義です。高レベルプログラム言語は、BEFOREトリガ内ではNEW行の生成列へのアクセスを避けるべきです。 BEFOREトリガでの生成列の値の変更は無視され、上書きされます。

If more than one trigger is defined for the same event on the same relation, the triggers will be fired in alphabetical order by trigger name. In the case of <literal>BEFORE</literal> and <literal>INSTEAD OF</literal> triggers, the possibly-modified row returned by each trigger becomes the input to the next trigger. If any <literal>BEFORE</literal> or <literal>INSTEAD OF</literal> trigger returns <symbol>NULL</symbol>, the operation is abandoned for that row and subsequent triggers are not fired (for that row). 同一リレーション、同一イベントに対して1つ以上のトリガが定義された場合、トリガはその名前のアルファベット順に発生します。 BEFOREトリガとINSTEAD OFトリガの場合では、各トリガで返される、変更された可能性がある行が次のトリガの入力となります。 もし、あるBEFOREトリガやINSTEAD OFトリガがNULLを返したら、(いまのところ)操作はその行で中断し、残りのトリガは発生しません。

A trigger definition can also specify a Boolean <literal>WHEN</literal> condition, which will be tested to see whether the trigger should be fired. In row-level triggers the <literal>WHEN</literal> condition can examine the old and/or new values of columns of the row. (Statement-level triggers can also have <literal>WHEN</literal> conditions, although the feature is not so useful for them.) In a <literal>BEFORE</literal> trigger, the <literal>WHEN</literal> condition is evaluated just before the function is or would be executed, so using <literal>WHEN</literal> is not materially different from testing the same condition at the beginning of the trigger function. However, in an <literal>AFTER</literal> trigger, the <literal>WHEN</literal> condition is evaluated just after the row update occurs, and it determines whether an event is queued to fire the trigger at the end of statement. So when an <literal>AFTER</literal> trigger's <literal>WHEN</literal> condition does not return true, it is not necessary to queue an event nor to re-fetch the row at end of statement. This can result in significant speedups in statements that modify many rows, if the trigger only needs to be fired for a few of the rows. <literal>INSTEAD OF</literal> triggers do not support <literal>WHEN</literal> conditions. トリガ定義は、トリガを発動するかどうかをWHEN句の論理条件で指定することも可能です。 行レベルトリガにおいて、WHEN条件は行の列の古い値と(あるいは)新しい値を検索することができます。 (あまり有用ではありませんが、文レベルトリガでもWHEN条件で同じことができます。) BEFOREトリガでは、実質的にトリガ関数の開始時と同じ条件で検査できるように、WHEN条件の評価が関数の実施直前になされます。 したがって、WHENを使用することは、トリガ関数の最初に同じ条件をテストすることと実質的に変わりません。 しかしAFTERトリガでは、WHEN条件の評価は行の更新直後に行われ、文の終わり(コミット時)にトリガを発動するためのイベントを待ち行列に入れるかどうかを決めます。 そのため、あるAFTERトリガのWHEN条件が真を返さなかった場合は、イベントを待ち行列に入れる必要も文の終わりに行を再取得する必要もありません。 これは、大量の行の変更が発生するけれども、トリガがその内の少数の行に対してのみ発動させる必要がある、といった文の処理速度を大幅に上げる効果があります。 INSTEAD OFトリガはWHEN条件をサポートしていません。

Typically, row-level <literal>BEFORE</literal> triggers are used for checking or modifying the data that will be inserted or updated. For example, a <literal>BEFORE</literal> trigger might be used to insert the current time into a <type>timestamp</type> column, or to check that two elements of the row are consistent. Row-level <literal>AFTER</literal> triggers are most sensibly used to propagate the updates to other tables, or make consistency checks against other tables. The reason for this division of labor is that an <literal>AFTER</literal> trigger can be certain it is seeing the final value of the row, while a <literal>BEFORE</literal> trigger cannot; there might be other <literal>BEFORE</literal> triggers firing after it. If you have no specific reason to make a trigger <literal>BEFORE</literal> or <literal>AFTER</literal>, the <literal>BEFORE</literal> case is more efficient, since the information about the operation doesn't have to be saved until end of statement. 通常、行レベルのBEFOREトリガは、挿入あるいは更新される予定のデータの検査や変更のために使用されます。 例えば、BEFOREトリガは、timestamp型の列に現在時刻を挿入するために、あるいは行の2つの要素の整合性を検査するために使用される可能性があります。 行レベルのAFTERトリガは、ほとんど常識的に他のテーブルに更新を伝播させるために、あるいは他のテーブルとの整合性を検査するために使用されます。 こうした仕事の切り分け理由は、AFTERトリガは行の最終値を見ることができ、BEFOREトリガは見ることができないという点です。 その後に他のBEFOREトリガが起動する可能性があります。 トリガをBEFOREにするかAFTERにするかを決める時に特別な理由がないのであれば、操作の情報を行が終わるまで保持する必要がない分、BEFOREを使う方が効率的です。

If a trigger function executes SQL commands then these commands might fire triggers again. This is known as cascading triggers. There is no direct limitation on the number of cascade levels. It is possible for cascades to cause a recursive invocation of the same trigger; for example, an <command>INSERT</command> trigger might execute a command that inserts an additional row into the same table, causing the <command>INSERT</command> trigger to be fired again. It is the trigger programmer's responsibility to avoid infinite recursion in such scenarios. トリガ関数がSQLコマンドを処理する場合、これらの問い合わせがトリガを再度発行することがあります。 これはカスケードされたトリガと呼ばれます。 カスケードの段数に直接的な制限はありません。 カスケードの場合、同じトリガを再帰的に呼び出すことが可能です。 例えば、INSERTトリガで同じテーブルに追加の行を挿入する問い合わせが実行された場合、その結果としてINSERTトリガが再度発行されます。 こうした状況で無限再帰を防ぐのは、トリガプログラマの責任です。

When a trigger is being defined, arguments can be specified for it. The purpose of including arguments in the trigger definition is to allow different triggers with similar requirements to call the same function. As an example, there could be a generalized trigger function that takes as its arguments two column names and puts the current user in one and the current time stamp in the other. Properly written, this trigger function would be independent of the specific table it is triggering on. So the same function could be used for <command>INSERT</command> events on any table with suitable columns, to automatically track creation of records in a transaction table for example. It could also be used to track last-update events if defined as an <command>UPDATE</command> trigger. トリガを定義する時、そのトリガ用の引数を指定することができます。 トリガ定義に引数を含めた目的は、似たような要求の異なるトリガに同じ関数を呼び出すことができるようにすることです。 例えば、2つの列名を引数とし、片方に現在のユーザをもう片方に現在のタイムスタンプを取る、汎化トリガ関数があるとします。 適切に作成すれば、この関数が特定のトリガの発行元となるテーブルに依存することはなくなります。 同じ関数を使用して、例えば、トランザクションテーブルに作成記録を自動的に登録させるために、適切な列を持つ任意のテーブルのINSERTイベントに使用することができます。 また、UPDATEとして定義すれば、最終更新イベントを追跡するために使用することも可能です。

Each programming language that supports triggers has its own method for making the trigger input data available to the trigger function. This input data includes the type of trigger event (e.g., <command>INSERT</command> or <command>UPDATE</command>) as well as any arguments that were listed in <command>CREATE TRIGGER</command>. For a row-level trigger, the input data also includes the <varname>NEW</varname> row for <command>INSERT</command> and <command>UPDATE</command> triggers, and/or the <varname>OLD</varname> row for <command>UPDATE</command> and <command>DELETE</command> triggers. トリガをサポートするプログラミング言語はそれぞれ独自の方法で、トリガ関数で利用できるトリガの入力データを作成します。 この入力データにはトリガイベント種類（例えばINSERTやUPDATEなど、CREATE TRIGGERで指定された全ての引数）が含まれます。 行レベルトリガの入力データには、INSERTおよびUPDATEトリガの場合はNEW行が、UPDATEおよびDELETEトリガの場合はOLD行が含まれます。

By default, statement-level triggers do not have any way to examine the individual row(s) modified by the statement. But an <literal>AFTER STATEMENT</literal> trigger can request that <firstterm>transition tables</firstterm> be created to make the sets of affected rows available to the trigger. <literal>AFTER ROW</literal> triggers can also request transition tables, so that they can see the total changes in the table as well as the change in the individual row they are currently being fired for. The method for examining the transition tables again depends on the programming language that is being used, but the typical approach is to make the transition tables act like read-only temporary tables that can be accessed by SQL commands issued within the trigger function. デフォルトでは、文レベルトリガには文によって変更された個々の行を検査するための手段がありません。 しかし、トリガがアクセスできる影響を受けた行の集合を作成するために、AFTER STATEMENTトリガは、遷移テーブル(transition tables)の作成を依頼することができます。 AFTER ROWトリガも遷移テーブルを依頼できるので、発動中の個々の行における変更だけでなく、テーブル全体におけるすべての変更を見ることができます。 遷移テーブルを検査する方法も使用中のプログラミング言語に依存しますが、典型的な方法は、トリガ関数の中で発行するSQLコマンドでアクセスできる、読み込み専用の一時テーブルのように振る舞う遷移テーブルを作成することです。