34.54. triggers

Представление triggers показывает все триггеры, определённые в текущей базе данных для таблиц и представлений, к которым имеет доступ текущий пользователь (являясь владельцем или имея некоторые права, кроме SELECT).

Таблица 34-52. Колонки triggers

ИмяТип данныхОписание
trigger_catalogsql_identifierИмя базы данных, содержащей триггер (всегда текущая база)
trigger_schemasql_identifierИмя схемы, содержащей триггер
trigger_namesql_identifierИмя триггера
event_manipulationcharacter_dataСобытие, вызывающие срабатывание триггера (INSERT, UPDATE или DELETE)
event_object_catalogsql_identifierИмя базы данных, содержащей таблицу, для которой определён триггер (всегда текущая база)
event_object_schemasql_identifierИмя схемы, содержащей таблицу, для которой определён триггер
event_object_tablesql_identifierИмя таблицы, для которой определён триггер
action_ordercardinal_numberЕщё не реализовано
action_conditioncharacter_dataУсловие WHEN триггера, либо NULL, если его нет (так же NULL, если таблица не принадлежит текущей активной роли)
action_statementcharacter_dataОператор, выполняемый триггером (в настоящее время всегда EXECUTE PROCEDURE функция(...))
action_orientationcharacter_dataОпределяет, срабатывает ли триггер для каждой обрабатываемой строки или только для каждого оператора (ROW или STATEMENT)
action_timingcharacter_dataМомент срабатывания триггера (BEFORE (до), AFTER (после) или INSTEAD OF (вместо))
action_reference_old_tablesql_identifierОтносится к функциональности, отсутствующей в PostgreSQL
action_reference_new_tablesql_identifierОтносится к функциональности, отсутствующей в PostgreSQL
action_reference_old_rowsql_identifierОтносится к функциональности, отсутствующей в PostgreSQL
action_reference_new_rowsql_identifierОтносится к функциональности, отсутствующей в PostgreSQL
createdtime_stampОтносится к функциональности, отсутствующей в PostgreSQL

Триггеры в PostgreSQL несовместимы со стандартом в двух аспектах, которые влияют на их представление в информационной схеме. Во-первых, имена триггеров являются локальными для каждой таблицы в PostgreSQL, а не независимыми объектами схемы. Таким образом, в одной схеме могут быть дублирующиеся имена триггеров, если они принадлежат разным таблицам. (Значения trigger_catalog и trigger_schema на самом деле относятся к таблице, для которой определён триггер.) Во-вторых, триггеры в PostgreSQL могут срабатывать при нескольких событиях (например, ON INSERT OR UPDATE), тогда как стандарт SQL допускает только одно событие. Если триггер настроен на несколько событий, он представляется в информационной схеме в виде нескольких строк, по одной для каждого типа события. Вследствие этих двух особенностей, первичный ключ в представлении triggers на самом деле (trigger_catalog, trigger_schema, event_object_table, trigger_name, event_manipulation), а не (trigger_catalog, trigger_schema, trigger_name), как должно быть согласно стандарту SQL. Однако, если определять триггеры в строгом соответствии со стандартом SQL (чтобы имена триггеров были уникальны в схеме и каждый триггер связывался только с одним событием), это расхождение никак не проявится.

Замечание: До PostgreSQL 9.1 в этом представлении колонки action_timing, action_reference_old_table, action_reference_new_table, action_reference_old_row и action_reference_new_row назывались condition_timing, condition_reference_old_table, condition_reference_new_table, condition_reference_old_row и condition_reference_new_row, соответственно. Старые имена были продиктованы стандартом SQL:1999. Новые имена соответствуют стандарту SQL:2003 и более поздним.

34.54. triggers

The view triggers contains all triggers defined in the current database on tables and views that the current user owns or has some privilege other than SELECT on.

Table 34-52. triggers Columns

NameData TypeDescription
trigger_catalogsql_identifierName of the database that contains the trigger (always the current database)
trigger_schemasql_identifierName of the schema that contains the trigger
trigger_namesql_identifierName of the trigger
event_manipulationcharacter_data Event that fires the trigger (INSERT, UPDATE, or DELETE)
event_object_catalogsql_identifier Name of the database that contains the table that the trigger is defined on (always the current database)
event_object_schemasql_identifierName of the schema that contains the table that the trigger is defined on
event_object_tablesql_identifierName of the table that the trigger is defined on
action_ordercardinal_numberNot yet implemented
action_conditioncharacter_dataWHEN condition of the trigger, null if none (also null if the table is not owned by a currently enabled role)
action_statementcharacter_data Statement that is executed by the trigger (currently always EXECUTE PROCEDURE function(...))
action_orientationcharacter_data Identifies whether the trigger fires once for each processed row or once for each statement (ROW or STATEMENT)
action_timingcharacter_data Time at which the trigger fires (BEFORE, AFTER, or INSTEAD OF)
action_reference_old_tablesql_identifierApplies to a feature not available in PostgreSQL
action_reference_new_tablesql_identifierApplies to a feature not available in PostgreSQL
action_reference_old_rowsql_identifierApplies to a feature not available in PostgreSQL
action_reference_new_rowsql_identifierApplies to a feature not available in PostgreSQL
createdtime_stampApplies to a feature not available in PostgreSQL

Triggers in PostgreSQL have two incompatibilities with the SQL standard that affect the representation in the information schema. First, trigger names are local to each table in PostgreSQL, rather than being independent schema objects. Therefore there can be duplicate trigger names defined in one schema, so long as they belong to different tables. (trigger_catalog and trigger_schema are really the values pertaining to the table that the trigger is defined on.) Second, triggers can be defined to fire on multiple events in PostgreSQL (e.g., ON INSERT OR UPDATE), whereas the SQL standard only allows one. If a trigger is defined to fire on multiple events, it is represented as multiple rows in the information schema, one for each type of event. As a consequence of these two issues, the primary key of the view triggers is really (trigger_catalog, trigger_schema, event_object_table, trigger_name, event_manipulation) instead of (trigger_catalog, trigger_schema, trigger_name), which is what the SQL standard specifies. Nonetheless, if you define your triggers in a manner that conforms with the SQL standard (trigger names unique in the schema and only one event type per trigger), this will not affect you.

Note: Prior to PostgreSQL 9.1, this view's columns action_timing, action_reference_old_table, action_reference_new_table, action_reference_old_row, and action_reference_new_row were named condition_timing, condition_reference_old_table, condition_reference_new_table, condition_reference_old_row, and condition_reference_new_row respectively. That was how they were named in the SQL:1999 standard. The new naming conforms to SQL:2003 and later.