Posttriggers

Posttriggers, typically called AFTER triggers in relational databases, are database objects that execute in response to a data modification statement on a table, after the operation has completed. They may be defined to run for each affected row (row-level) or once per statement (statement-level).

During execution, posttriggers have access to the state of the modified row through OLD and NEW values in row-level triggers, and can perform actions such as writing audit logs, updating related tables, or initiating external processes. Because they run after the triggering statement, they do not affect the data that was modified by that statement, though they still run within the same transaction in many systems. Some databases allow deferring posttrigger work until the end of the transaction or after commit for certain tasks.

Common use cases include audit logging for compliance, maintaining derived data in separate tables, synchronizing changes to other systems, regenerating caches, or enforcing business workflows that rely on the final state of a modification.

Design considerations: posttriggers can impact performance because they execute synchronously; they can cause cascading changes or recursive triggers; they may complicate debugging and maintenance. To mitigate, developers may prefer asynchronous processing or use a dedicated change data capture mechanism.

Relation to other triggers: posttriggers complement pretriggers and INSTEAD OF triggers (which replace the operation on views). In some systems, posttriggers can be used for cross-table integrity checks, while in others, complex validations are better placed in the application layer. Examples across systems include PostgreSQL AFTER INSERT triggers writing to an audit_log; MySQL AFTER UPDATE triggers; Oracle AFTER ROW triggers. The exact capabilities vary by database.