PostgreSQL
Triggers BEFORE, AFTER e INSTEAD OF para validación, auditoría y reacciones transaccionales, con sus riesgos de comportamiento implícito y costo por fila.
Un trigger garantiza que una reacción ocurra sin importar qué cliente modifica la tabla. Esa fuerza también es su riesgo: introduce comportamiento implícito dentro de cada escritura.
Un trigger enlaza un evento con una función:
INSERT / UPDATE / DELETE / TRUNCATE
→ BEFORE / AFTER / INSTEAD OF
→ ROW o STATEMENT
→ función triggerTodo ocurre dentro de la misma transacción, salvo mecanismos externos posteriores. AFTER significa después de la operación, no después del commit.
CREATE FUNCTION app.set_updated_at()
RETURNS trigger
LANGUAGE plpgsql
AS $$
BEGIN
NEW.updated_at := clock_timestamp();
RETURN NEW;
END;
$$;
CREATE TRIGGER products_set_updated_at
BEFORE UPDATE ON app.products
FOR EACH ROW
EXECUTE FUNCTION app.set_updated_at();Un BEFORE puede modificar NEW o devolver NULL para omitir la fila en ciertos contextos. Debe documentarse porque el resultado final puede diferir del SQL enviado.
NEW disponible.OLD y NEW.OLD.La disponibilidad depende del evento y nivel.
FOR EACH ROW ejecuta una vez por fila. Un update de un millón de filas invoca un millón de veces.
FOR EACH STATEMENT ejecuta una vez por statement y puede usar transition tables:
CREATE TRIGGER orders_audit
AFTER UPDATE ON orders
REFERENCING OLD TABLE AS old_rows NEW TABLE AS new_rows
FOR EACH STATEMENT
EXECUTE FUNCTION audit_orders();Esto permite procesar conjuntos y evitar lógica row-by-row.
Validar o transformar la fila antes de escribir. Prefiere constraints y generated columns cuando expresan la regla.
Reaccionar a datos ya validados y escritos dentro de la transacción. Útil para auditoría local u outbox.
Implementar escrituras sobre views no actualizables automáticamente.
Varios triggers del mismo evento/timing se ejecutan según reglas de nombre. No construyas un workflow frágil basado en nombres alfabéticos; consolida responsabilidades o documenta dependencias.
Un trigger puede registrar:
INSERT INTO audit_log(table_name, row_id, old_data, new_data, changed_by)
VALUES (TG_TABLE_NAME, NEW.id, to_jsonb(OLD), to_jsonb(NEW), current_user);Decisiones:
Un audit trigger no reemplaza logs de acceso ni evidencia inmutable externa.
Un AFTER trigger puede insertar evento outbox en la misma transacción. Ventaja: ningún cliente olvida hacerlo. Coste: el trigger debe conocer el contrato de eventos y aumenta acoplamiento.
No publiques HTTP/Kafka directamente desde el trigger. La llamada externa no revierte y mantiene la transacción esperando.
Prefiere:
NOT NULL, CHECK, UNIQUE, FK.Usa trigger cuando la regla depende de varios eventos/tablas y no puede expresarse declarativamente con claridad.
Un trigger puede modificar otra tabla que dispara otro trigger o volver a la misma. Controla:
pg_trigger_depth() cuando sea necesario.WHEN.UPDATE OF ....Recursión accidental puede agotar stack o generar trabajo exponencial.
CREATE TRIGGER orders_status_audit
AFTER UPDATE OF status ON orders
FOR EACH ROW
WHEN (OLD.status IS DISTINCT FROM NEW.status)
EXECUTE FUNCTION audit_status_change();Evita ejecutar cuando el valor no cambió.
Si el trigger falla, falla el statement y normalmente la transacción queda abortada. El cliente debe ver un SQLSTATE útil. Un error genérico del trigger puede hacer difícil diagnosticar la operación original.
La función usa por defecto privilegios del invoker, pero ownership y SECURITY DEFINER pueden cambiarlo. Aplica las mismas reglas de search path seguro. Revoca permisos directos que permitirían saltarse el boundary cuando el trigger es parte de la seguridad.
Mide:
Un trigger barato para una fila puede ser devastador en un backfill.
Los triggers deben formar parte de migraciones versionadas. Durante backfills decide explícitamente si deben ejecutarse; deshabilitarlos puede romper integridad y requiere privilegios altos. Nunca lo hagas como solución improvisada.
INSERT ... ON CONFLICT DO UPDATE puede activar triggers de INSERT/UPDATE según camino.COPY FROM ejecuta triggers de fila ordinarios.session_replication_role cambian qué triggers se ejecutan.AFTER no significa después del commit?WHEN?Particionamiento declarativo divide almacenamiento y mantenimiento sin confundirlo con sharding.