Vamos a lo básico: Un trigger es una rutina que realiza una acción ante un evendo directo sobre la tabla, definiendo como tales sólo los INSERT, UPDATE y DELETE. Su acción es instantanea y genera un bloqueo sobre la tabla en la que se definen, en tanto el trigger se ejecuta.
En PostgreSQL, se admite que la lógica de un TRIGGER esté separada del cuerpo del trigger mismo, y depositada en una stored function. Esto no sucede con otros DBMS. Pero una condición mandatoria en todos los DBMS sobre los TRIGGER es que
no se puede generar un trigger que invoque una acción que vuelva a disparar el trigger, o que pueda disparar otro sobre la misma tabla. Ese tipo de situaciones no son licitas.
Pero una condición que compoarten todos los DBMS rtambién, es que un TRIGGER, como cualquier acción sobre tablas,
debe tener un tiempo de terminación finito y reducido, que debe ser menor al timeout definido globalmenbte para los procesos... y
no puedes, ni te conviene hablar de timeouts de 10.800 segudos. Eso es simplemente absurdo.
Ahora bien, existen dentro de Postgre ciertos recursos de uso posible que son los
EVENT TRIGGER, que no son exactamente lo mismo. Es probable que te refieras a ellos y que sea eso lo que necesites.
http://www.postgresql.org/docs/8.4/s...pq-events.html http://www.postgresql.org/docs/9.3/s...-triggers.html
De lo contrario, yo pensaría sreiamente en usar el cron (Linux) o tareas Programadas (Win) para invocar un proceso de ejecución por tiempo que realice la tarea.