How do triggers work and what are the risks?

A trigger is attached to a table and an event. Row-level triggers fire once per changed row; statement-level triggers fire once per statement. The trigger function can read OLD and NEW values and modify data, reject the change, or write to another table.

CREATE FUNCTION audit_order_status() RETURNS trigger
LANGUAGE plpgsql
AS $$
BEGIN
  INSERT INTO order_status_audit (
    order_id, old_status, new_status, changed_at
  )
  VALUES (NEW.id, OLD.status, NEW.status, now());
  RETURN NEW;
END;
$$;

CREATE TRIGGER trg_order_status_audit
AFTER UPDATE OF status ON orders
FOR EACH ROW
EXECUTE FUNCTION audit_order_status();

Where triggers help and hurt

• Audit trails that must capture every change regardless of application path
• Maintaining a denormalized column inside the same transaction
• Enforcing a complex invariant that cannot be expressed as a constraint
• Hidden control flow that surprises developers reading only application code
• Recursive or cascading triggers that are difficult to trace
• Bulk operations where per-row work becomes a performance problem

Triggers run in the same transaction as the statement, so a failure rolls back the whole change. That is good for consistency but dangerous if the trigger performs slow or external work. Keep trigger logic small, deterministic, and well documented.