An event trigger fires whenever the event with which it is associated
occurs in the database in which it is defined. Currently, the
supported events are
<literal>login</literal>,
<literal>ddl_command_start</literal>,
<literal>ddl_command_end</literal>,
<literal>table_rewrite</literal>
and <literal>sql_drop</literal>.
Support for additional events may be added in future releases.
《マッチ度[86.876640]》イベントトリガは、関連づけられたイベントが、定義されたデータベースで起こるたびに実行されます。
今のところサポートされているイベントは、login
、ddl_command_start
、ddl_command_end
、table_rewrite
、sql_drop
です。
今後のリリースで新たなイベントが追加されるかもしれません。
《機械翻訳》イベントトリガは、それが関連付けられているイベントが、それが定義されているデータベースで発生するたびに発生します。
現在サポートされているイベントは、login
、ddl_command_start
、ddl_command_end
、table_rewrite
およびsql_drop
です。
追加のイベントのサポートは、将来のリリースで追加される可能性があります。
The <literal>login</literal> event occurs when an authenticated user logs
into the system. Any bug in a trigger procedure for this event may
prevent successful login to the system. Such bugs may be worked around by
setting <xref linkend="guc-event-triggers"/> to <literal>false</literal>
either in a connection string or configuration file. Alternatively, you can
restart the system in single-user mode (as event triggers are
disabled in this mode). See the <xref linkend="app-postgres"/> reference
page for details about using single-user mode.
The <literal>login</literal> event will also fire on standby servers.
To prevent servers from becoming inaccessible, such triggers must avoid
writing anything to the database when running on a standby.
Also, it's recommended to avoid long-running queries in
<literal>login</literal> event triggers. Note that, for instance,
canceling a connection in <application>psql</application> will not cancel
the in-progress <literal>login</literal> trigger.
login
イベントは、認証されたユーザがシステムにログインするときに発生します。
このイベントのトリガプロシージャにおけるバグは、システムへのログインの成功を妨げる可能性があります。
このようなバグは、接続文字列または設定ファイルでevent_triggersをfalse
に設定することで回避できます。
あるいは、シングルユーザモードでシステムを再起動することでも回避できます(このモードではイベントトリガが無効になっているため)。
シングルユーザモードの使用方法の詳細については、postgresのリファレンスページを参照してください。
login
イベントはスタンバイサーバでも実行されます。
サーバがアクセスできなくなるのを防ぐために、このようなトリガは、スタンバイで実行されているときにはデータベースに何も書き込まないようにする必要があります。
また、login
イベントトリガでの長時間実行する問い合わせは避けることをお勧めします。
例えば、psqlで接続を取り消しても進行中のlogin
トリガを中断しないことに注意してください。
For an example on how to use the <literal>login</literal> event trigger,
see <xref linkend="event-trigger-database-login-example"/>.
《機械翻訳》login
例の使用方法については、38.5を参照してください。
イベントトリガ
The <literal>ddl_command_start</literal> event occurs just before the
execution of a DDL command. DDL commands in this context are:
《機械翻訳》ddl_command_start
イベントは前でのみ発生しますDDLコマンドの実行。
このコンテキストのDDLコマンドは次のとおりです。
CREATE
ALTER
DROP
COMMENT
GRANT
IMPORT FOREIGN SCHEMA
REINDEX
REFRESH MATERIALIZED VIEW
REVOKE
SECURITY LABEL
ddl_command_start
also occurs just before the
execution of a SELECT INTO
command, since this is
equivalent to CREATE TABLE AS
.
As an exception, this event does not occur for DDL commands targeting shared objects: 《機械翻訳》例外として、このイベントは、共有オブジェクトをターゲットにするDDLコマンドでは発生しません。
databases
roles (role definitions and role memberships)
tablespaces
parameter privileges
ALTER SYSTEM
This event also does not occur for commands targeting event triggers themselves.
No check whether the affected object exists or doesn't exist is performed before the event trigger fires. 《機械翻訳》イベントトリガ火災の前では、被災オブジェクトの有無にかかわらずチェックは行われません。
The <literal>ddl_command_end</literal> event occurs just after the execution of
the same set of commands as <literal>ddl_command_start</literal>. To
obtain more details on the <acronym>DDL</acronym>
operations that took place, use the set-returning function
<literal>pg_event_trigger_ddl_commands()</literal> from the
<literal>ddl_command_end</literal> event trigger code (see
<xref linkend="functions-event-triggers"/>). Note that the trigger fires
after the actions have taken place (but before the transaction commits),
and thus the system catalogs can be read as already changed.
《マッチ度[87.135506]》ddl_command_end
イベントは、ddl_command_startイベントが対象とする同様のコマンドの実行後に発生します。
発生したDDL操作のより詳細を取得するには、ddl_command_end
イベントトリガコード(9.30を参照してください)で集合を返す関数pg_event_trigger_ddl_commands()
を使ってください。
トリガはアクションが起きた後(ただし、トランザクションのコミットの前)に起動し、システムカタログは既に変更されたものとして読まれることに注意してください。
《機械翻訳》ddl_command_end
イベントは、ddl_command_start
と同じコマンドセットの実行直後に発生します。
行われたDDL操作の詳細を取得するには、セットを返す関数pg_event_trigger_ddl_commands()
ddl_command_end
イベントトリガコード9.30を参照からを使用します。
アクションが行われた後にトリガが起動するノート(ただし、トランザクションの前はコミットします)。
したがって、システムカタログはすでに変更されているものとして読み取ることができます。
The <literal>sql_drop</literal> event occurs just before the
<literal>ddl_command_end</literal> event trigger for any operation that drops
database objects. Note that besides the obvious <literal>DROP</literal>
commands, some <literal>ALTER</literal> commands can also trigger an
<literal>sql_drop</literal> event.
《機械翻訳》sql_drop
イベントは、前ddl_command_end
イベントトリガを落とすオペレーションだけで発生します。
ノートは、明白なDROP
コマンドの他に、いくつかのALTER
コマンドはsql_drop
イベントをトリガすることもできます。
データベースオブジェクト
To list the objects that have been dropped, use the
set-returning function <literal>pg_event_trigger_dropped_objects()</literal> from the
<literal>sql_drop</literal> event trigger code (see
<xref linkend="functions-event-triggers"/>). Note that
the trigger is executed after the objects have been deleted from the
system catalogs, so it's not possible to look them up anymore.
《機械翻訳》削除されたオブジェクトをリストするためには、集合を返す関数pg_event_trigger_dropped_objects()
sql_drop
イベントトリガコード9.30を参照.ノートからを使用します。
トリガは、システムカタログからオブジェクトが削除された後に実行されるため、それらを検索することはできません。
The <literal>table_rewrite</literal> event occurs just before a table is
rewritten by some actions of the commands <literal>ALTER TABLE</literal> and
<literal>ALTER TYPE</literal>. While other
control statements are available to rewrite a table,
like <literal>CLUSTER</literal> and <literal>VACUUM</literal>,
the <literal>table_rewrite</literal> event is not triggered by them.
To find the OID of the table that was rewritten, use the function
<literal>pg_event_trigger_table_rewrite_oid()</literal>, to discover the
reason(s) for the rewrite, use the function
<literal>pg_event_trigger_table_rewrite_reason()</literal> (see <xref
linkend="functions-event-triggers"/>).
《マッチ度[78.475336]》コマンドALTER TABLE
やALTER TYPE
のアクションによりテーブルが書き換えられる直前に、table_rewrite
イベントは発生します。
CLUSTER
やVACUUM
のような他の制御文でもテーブルを書き換えられますが、それらではtable_rewrite
イベントは引き起こされません。
書き換えられたテーブルのOIDを見つけるには、関数pg_event_trigger_table_rewrite_oid()
(9.30を参照)を使用します。
書き換えられた理由を知るには、関数pg_event_trigger_table_rewrite_reason()
を使用します。
《機械翻訳》table_rewrite
イベントは、コマンドALTER TABLE
およびALTER TYPE
のいくつかのアクションによって表が書き換えられる前でのみ発生します。
CLUSTER
およびVACUUM
などの他のコントロールステートメントは、表を書き換えるために使用できますが、table_rewrite
イベントはこれらのステートメントによってトリガされません。
書き換えられたテーブルのoidを調べるには関数pg_event_trigger_table_rewrite_oid()
を使用し、書き換えられた理由を調べるには関数pg_event_trigger_table_rewrite_reason()
を使用します(9.30を参照)。
Event triggers (like other functions) cannot be executed in an aborted
transaction. Thus, if a DDL command fails with an error, any associated
<literal>ddl_command_end</literal> triggers will not be executed. Conversely,
if a <literal>ddl_command_start</literal> trigger fails with an error, no
further event triggers will fire, and no attempt will be made to execute
the command itself. Similarly, if a <literal>ddl_command_end</literal> trigger
fails with an error, the effects of the DDL statement will be rolled
back, just as they would be in any other case where the containing
transaction aborts.
イベントトリガは(他の関数のように)中断したトランザクションでは実行されません。
従って、DDLコマンドがエラーで失敗した場合、関連するddl_command_end
トリガは実行されません。
逆に、もしddl_command_start
トリガがエラーで失敗した場合、他のイベントトリガは起動されず、コマンド自体も実行されません。
同様に、もしddl_command_end
トリガがエラーで失敗した場合、それを含むトランザクションが失敗した場合のようにDDL文はロールバックされます。
Event triggers are created using the command <xref linkend="sql-createeventtrigger"/>.
In order to create an event trigger, you must first create a function with
the special return type <literal>event_trigger</literal>. This function
need not (and may not) return a value; the return type serves merely as
a signal that the function is to be invoked as an event trigger.
イベントトリガは、コマンドCREATE EVENT TRIGGERを使用して作成されます。
イベントトリガを作成するために、まず特別な型event_trigger
を返す関数を作る必要があります。
この関数は値を返す必要はありません。というのも、その戻り値型は単にシグナルとして、その関数がイベントトリガを呼び出していることを示しているだけだからです。
If more than one event trigger is defined for a particular event, they will fire in alphabetical order by trigger name. 特定のイベントに対して複数のイベントトリガが定義された場合、トリガ名のアルファベット順で起動されます。
A trigger definition can also specify a <literal>WHEN</literal>
condition so that, for example, a <literal>ddl_command_start</literal>
trigger can be fired only for particular commands which the user wishes
to intercept. A common use of such triggers is to restrict the range of
DDL operations which users may perform.
トリガ定義はWHEN
条件で特定されます。そのため、例えばddl_command_start
トリガはユーザが望む特定のコマンドのみを契機に実行させることができます。
このようなトリガの一般的な使い方として、ユーザが実行するかもしれないDDL文の範囲を狭めることができます。