Postgres tiene algunas interfaces cliente como Perl, Tcl, Python y C, así como dos Lenguajes Procedurales (PL). También es posible llamar a funciones C como acciones trigger. Notar que los eventos trigger a nivel STATEMENT no están soportados en la versión actual. Actualmente es posible especificar BEFORE o AFTER en los INSERT, DELETE o UPDATE de un registro como un evento trigger.
Si un evento trigger ocurre, el administrador de triggers (llamado Ejecutor) inicializa la estructura global TriggerData *CurrentTriggerData (descrita más abajo) y llama a la función trigger para procesar el evento.
La función trigger debe ser creada antes que el trigger, y debe hacerse como una función sin argumentos, y códigos de retorno opacos.
La sintaxis para la creación de triggers es la siguiente:
CREATE TRIGGER <trigger name> <BEFORE|AFTER> <INSERT|DELETE|UPDATE>
ON <relation name> FOR EACH <ROW|STATEMENT>
EXECUTE PROCEDURE <procedure name> (<function args>);El nombre del trigger se usará si se desea eliminar el trigger. Se usa como argumento del comando DROP TRIGGER.
La palabra siguiente determina si la función debe ser llamada antes (BEFORE) o después (AFTER) del evento.
El siguiente elemento del comando determina en que evento/s será llamada la función. Es posible especificar múltiples eventos utilizado el operador OR.
El nombre de la relación (relation name) determinará la tabla afectada por el evento.
La instrucción FOR EACH determina si el trigger se ejecutará para cada fila afectada o bien antes (o después) de que la secuencia se haya completado.
El nombre del procedimiento (procedure name) es la función C llamada.
Los argumentos son pasados a la función en la estructura CurrentTriggerData. El propósito de pasar los argumentos a la función es permitir a triggers diferentes con requisitos similares llamar a la misma función.
Además, la función puede ser utilizada para disparar distintas relaciones (estas funciones son llamadas "general trigger funcions").
Como ejemplo de utilización de lo descrito, se puede hacer una función general que toma como argumentos dos nombres de campo e inserta el nombre del usuario y la fecha (timestamp) actuales en ellos. Esto permite, por ejemplo, utilizar los triggers en los eventos INSERT para realizar un seguimiento automático de la creación de registros en una tabla de transacciones. Se podría utilizar también para registrar actualizaciones si es utilizado en un evento UPDATE.
Las funciones trigger retornan un área de tuplas (HeapTuple) al ejecutor. Esto es ignorado para trigger lanzados tras (AFTER) una operación INSERT, DELETE o UPDATE, pero permite lo siguiente a los triggers BEFORE: - retornar NULL e ignorar la operación para la tupla actual (y de este modo la tupla no será insertada/actualizada/borrada); - devolver un puntero a otra tupla (solo en eventos INSERT y UPDATE) que serán insertados (como la nueva versión de la tupla actualizada en caso de UPDATE) en lugar de la tupla original.
Notar que no hay inicialización por parte del CREATE TRIGGER handler. Esto será cambiado en el futuro. Además, si más de un trigger es definido para el mismo evento en la misma relación, el orden de ejecución de los triggers es impredecible. Esto puede ser cambiado en el futuro.
Si una función trigger ejecuta consultas SQL (utilizando SPI) entonces estas funciones pueden disparar nuevos triggers. Esto es conocido como triggers en cascada. No hay ninguna limitación explicita en cuanto al número de niveles de cascada.
Si un trigger es lanzado por un INSERT e inserta una nueva tupla en la misma relación, el trigger será llamado de nuevo (por el nuevo INSERT). Actualmente, no se proporciona ningún mecanismo de sincronización (etc) para estos casos pero esto puede cambiar. Por el momento, existe una función llamada funny_dup17() en los tests de regresión que utiliza algunas técnicas para parar la recursividad (cascada) en si misma...
En la version 6.4 ya existian los triggers, lo que eran triggers para
tuplos, (FOR EACH ROW) pero no para sentencias (FOR STATEMENT), por eso
creo que es importante poner disparadores para sentencias, no disparadores
solo.
Los trigger son parte de lo que se conoce como "elementos activos" de una
BD. Asi como lo son las constraints tales como NOT NULL, FOREIGN KEY,
PRIMARY KEY, CHECK. Una vez definidas ellas "se activaran" solo al ocurrir
un evento que las viole, un valor nulo en un campo con NOT NULL, etc.
Por
que entonces llamar triggers a los triggers? ;Con ellos se quizo dar mas
control al programador sobre los eventos que desencadenan un elemento
activo, se le conoce en ingles como ECA rules o event-condition-action
rule. Es por ello que los triggers tienen una clausula BEFORE, AFTER o
INSTEAD (por cierto pgsql no tiene INSTEAD) y bajo que evento (INSERT,
UPDATE, DELETE) pero de esta forma el trigger se ejecutara para tuplo (o
fila) sometido al evento (clausula FOR EACH ROW) pero el standard (que
pgsql no cubre completamente) dice que puede ser tambien FOR EACH
SENTENCE.
Esto provoca que se ejecute el trigger para toda la relacion (o
tabla) para la cual se define (clausula ON). La diferencia para los que lo
han programado, por ejemplo en plpgsql, queda clara entonces: cuando es
FOR EACH ROW en la funcion pgsql que implementa el trigger se tiene un
objeto NEW y uno OLD que se refiere a la tupla completa, en el trigger de
STATEMENT tiene un objeto NEW y OLD que son la relacion (o tabla)
completa.
Esta claro entonces que es un poco mas dificil implementar un
trigger para statement que para fila (todavia pgsql no lo tiene).
Finalmente este es un buen ejemplo de que por que pgsql dice que
"implementa un subconjunto extendido de SQL92", no hay trigger en SQL92,
son del SQL3.