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コマンドは、次の通りです。

<literal>ddl_command_start</literal> also occurs just before the execution of a <literal>SELECT INTO</literal> command, since this is equivalent to <literal>CREATE TABLE AS</literal>. ddl_command_startは、SELECT INTOコマンドが実行される直前にも発生します。 このコマンドはCREATE TABLE ASと同等であるためです。

As an exception, this event does not occur for DDL commands targeting shared objects: 例外として、このイベントは共有オブジェクトを対象とするDDLコマンドでは発生しません。

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. ddl_command_endイベントは、ddl_command_startイベントの対象と同じコマンド集合の実行直後に発生します。 発生したDDL操作のより詳細を取得するには、ddl_command_endイベントトリガコードで集合を返す関数pg_event_trigger_ddl_commands()を使用してください（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. 削除されたオブジェクトの一覧を確認するには、sql_dropイベントトリガコードで集合を返す関数pg_event_trigger_dropped_objects()を使用してください（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"/>). 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文の範囲を狭めることができます。