> For the complete documentation index, see [llms.txt](https://docs.postgresql.tw/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.postgresql.tw/client-interfaces/information-schema/infoschema-triggers.md).
# 35.57. 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 35.55. `triggers` Columns**
| Column Type
Description
|
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| trigger\_catalog sql\_identifier
Name of the database that contains the trigger (always the current database)
|
| trigger\_schema sql\_identifier
Name of the schema that contains the trigger
|
| trigger\_name sql\_identifier
Name of the trigger
|
| event\_manipulation character\_data
Event that fires the trigger (INSERT, UPDATE, or DELETE)
|
| event\_object\_catalog sql\_identifier
Name of the database that contains the table that the trigger is defined on (always the current database)
|
| event\_object\_schema sql\_identifier
Name of the schema that contains the table that the trigger is defined on
|
| event\_object\_table sql\_identifier
Name of the table that the trigger is defined on
|
| action\_order cardinal\_number
Firing order among triggers on the same table having the same event\_manipulation, action\_timing, and action\_orientation. In PostgreSQL, triggers are fired in name order, so this column reflects that.
|
| action\_condition character\_data
WHEN condition of the trigger, null if none (also null if the table is not owned by a currently enabled role)
|
| action\_statement character\_data
Statement that is executed by the trigger (currently always EXECUTE FUNCTION function(...))
|
| action\_orientation character\_data
Identifies whether the trigger fires once for each processed row or once for each statement (ROW or STATEMENT)
|
| action\_timing character\_data
Time at which the trigger fires (BEFORE, AFTER, or INSTEAD OF)
|
| action\_reference\_old\_table sql\_identifier
Name of the “old” transition table, or null if none
|
| action\_reference\_new\_table sql\_identifier
Name of the “new” transition table, or null if none
|
| action\_reference\_old\_row sql\_identifier
Applies to a feature not available in PostgreSQL
|
| action\_reference\_new\_row sql\_identifier
Applies to a feature not available in PostgreSQL
|
| created time\_stamp
Applies 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.
***
原文：[PostgreSQL 18.6 Documentation](https://www.postgresql.org/docs/18/infoschema-triggers.html)（英文原文，待翻譯）
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.postgresql.tw/client-interfaces/information-schema/infoschema-triggers.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.