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
トリガの実行は、トリガ実行を文の終わりではなく、トランザクションの終わりまで保留することができます。
すべての場合において、トリガはトリガが引き金となった文と同じトランザクションの一部として実行されるため、文またはトリガのいずれかがエラーを引き起こした場合、両方の結果がロールバックされます。
If an <command>INSERT</command> contains an <literal>ON CONFLICT
DO UPDATE</literal> clause, it is possible for row-level
<literal>BEFORE</literal> <command>INSERT</command> and then
<literal>BEFORE</literal> <command>UPDATE</command> triggers
to be executed on triggered rows. Such interactions can be
complex if the triggers are not idempotent because change made by
<literal>BEFORE</literal> <command>INSERT</command> triggers will be
seen by <literal>BEFORE</literal> <command>UPDATE</command> triggers,
including changes to <varname>EXCLUDED</varname> columns.
《機械翻訳》INSERT
包含がON CONFLICT DO UPDATE
句の場合、行-レベル前
INSERT
と前
UPDATE
のトリガをトリガされたローで実行できます。
前
INSERT
トリガによって行われた変更は、EXCLUDED
列への変更を含めて、前
UPDATE
トリガによって見られるため、トリガがべき等でない場合、このような相互作用は複雑になる可能性があります。
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.
《機械翻訳》ステートメント-レベルUPDATE
がトリガするノートは、ON CONFLICT DO UPDATE
が指定された場合に実行されます。
UPDATE
の影響を受けたローがあるかどうかは関係ありません。
UPDATE
パスが選択されたかどうかも関係ありません。
ON CONFLICT DO UPDATE
句付きのINSERT
は、最初に実行ステートメント-レベル前
INSERT
トリガー、次にステートメントレベル前
UPDATE
トリガー、続いてステートメント-レベルAFTER
UPDATE
トリガー、最後にステートメント-AFTER
INSERT
トリガーとなります。
レベル
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>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
型の値)を返すように選択することができます。
操作前に発行された行レベルのトリガでは以下の選択肢があります。
It can return <symbol>NULL</symbol> to skip the operation for the
current row. This instructs the executor to not perform the
row-level operation that invoked the trigger (the insertion,
modification, or deletion of a particular table row).
NULL
を返して、現在の行への操作を飛ばすことができます。
これは、エグゼキュータにトリガの元になった行レベルの操作(特定のテーブル行の挿入、更新、削除)を行わないよう指示します。
For row-level <command>INSERT</command>
and <command>UPDATE</command> triggers only, the returned row
becomes the row that will be inserted or will replace the row
being updated. This allows the trigger function to modify the
row being inserted or updated.
行レベルのINSERT
およびUPDATE
トリガの場合のみ、返される行が挿入される、もしくは実際に更新される行になります。
これにより、トリガ関数で、挿入される行もしくは更新される行を変更することができます。
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
トリガが再度発行されます。
こうした状況で無限再帰を防ぐのは、トリガプログラマの責任です。
If a foreign key constraint specifies referential actions (that is, cascading updates or deletes), those actions are performed via ordinary SQL update or delete commands on the referencing table. In particular, any triggers that exist on the referencing table will be fired for those changes. If such a trigger modifies or blocks the effect of one of these commands, the end result could be to break referential integrity. It is the trigger programmer's responsibility to avoid that. 《機械翻訳》外部キー制約が参照アクション(カスケード更新または削除)を指定している場合、これらのアクションは、参照テーブル上の通常のSQL更新または削除コマンドを介して実行されます。 特に、参照テーブルに存在するトリガーは、これらの変更に対して起動されます。 このようなトリガがこれらのコマンドのいずれかの効果を変更またはブロックすると、最終的に参照整合性を破壊する可能性があります。 それを回避するのはトリガプログラマの責任です。
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コマンドでアクセスできる、読み込み専用の一時テーブルのように振る舞う遷移テーブルを作成することです。