El comando NOTIFY envía un evento notify a cada aplicación frontend que previamente ha ejecutado LISTEN notifyname para la condición notify específica en la base de datos en curso.
La información pasada al "frontend" para un evento notify incluye el nombre de la condición notify y el PID de la notificación del proceso "backend". Es asunto del diseñador de la base de datos el definir los nombres de las condiciones que serán usadas en una base de datos dada y que significa cada una.
Comunmente, el nombre de una condición notify es el mismo que el de alguna tabla en la base de datos, y el evento notify esencialmente significa "He cambiado ésta tabla, echale un vistazo para ver los cambios". Pero dicha asociación no es obligada por lo comandos NOTIFY y LISTEN. Por ejemplo, un diseñador de bases de datos podría usar varios nombres de condición diferentes para señalar diferentes tipos de cambios en una misma tabla.
NOTIFY provee un modo simple de señalar o un mecanismo de comunicación entre procesos (IPC interprocess communication) para el conjunto de procesos que acceden a la misma base de datos Postgres. Se pueden construir mecanismos de más alto nivel usando tablas en la base de datos para pasar datos adicionales (más allá de un mero nombre de condición) desde el notificador al o a los que estén a la escucha.
Cuando se usa NOTIFY para señalar la ocurrencia de cambios en una tabla en particular, una técnica útil de programación es poner NOTIFY en una norma que es disparada por actualizaciones de la tabla. De esta manera, la notificación es automática cuando la tabla cambia, y el programador de la aplicación no puede olvidarse de ello de forma accidental.
NOTIFY interactúa con transacciones SQL de una manera importante. Primero, si se ejecuta un NOTIFY dentro de una transacción, lo eventos notify no son repartidos hasta y a menos que la transacción se haya hecho. Esto es adecuado, dado que si una transacción se aborta nos gustaría que todos los comandos dentro de ella no hubieran tenido efecto, incluyendo NOTIFY. Pero puede ser desconcertante si uno está esperando que los eventos notify se repartan inmediatamente. Segundo, si un "backend" a la escucha recibe una señal notify mientras está en una transacción, el evento notify no se repartirá al "frontend" conectado hasta justo después de que la transacción se haya completado (tanto si se ejecuta como si se aborta). De nuevo, la razón es que si un notify fuera repartido dentro de una transacción que después fue abortado, sería deseable que la notificación se deshiciera de alguna manera --- pero el "backend" no puede echar marcha atrás un notify una vez que ha sido enviado al "frontend". Por tanto los eventos notify son sólo repartidos entre transacciones. El resultado de ésto es que las aplicaciones que usan NOTIFY para señalar en tiempo real deberían tratar de mantener cortas sus transacciones.
NOTIFY se comporta como las señales Unix en un aspecto importante:si una misma condición es señalada varias veces en una sucesión rápida, los receptores puede que sólo recibieran un evento notify para varias ejecucuiones de NOTIFY. Por ello es mala idea depender del número de notificaciones recibidas. En cambio, usaremos NOTIFY para "despertar" a las aplicaciones que necesitan prestar atención a algo, y usaremos un objeto de base de datos (tal como una secuencia) para mantener un registro de lo que ha ocurrido o cuantas veces ha ocurrido.
Es usual para un "frontend" que envía NOTIFY estar él mismo a la escucha del mismo nombre notify. En ese caso recibirá un evento notify , justo igual que los otros "frontends" a la escucha. Dependiendo de la lógica de la aplicación, esto podría acarrear un trabajo inútil --- por ejemplo, releyendo una tabla de una base de datos para encontrar la misma actualización que ése mismo frontend acababa de escribir. En Postgres 6.4 y posteriores , es posible evitar dicho trabajo extra notificando si el PID del proceso de notificación del "backend" (suministrado en el mensaje del evento notify) es el mismo que el PID del backend de uno mismo (valga la redundancia) (disponible en libpq). Cuando son el mismo, el evento notificación es la recuperación del propio trabajo de uno mismo, y puede ser ignorado. (A pesar de lo que se dijo en el párrafo precedente, esto es una técnica segura. Postgres mantiene las auto-notificaciones separadas de las notificaciones que llegan de otros "backends", de manera que no puedes perder una notificación de fuera por ignorar tus propias notificaciones.(Si alguien entiende ésto que me lo explique))
name puede ser una cadena válica com un nombre; no es necesaría una relación con el nombre de la tabla en sí. Si name se encierra entre dobles comillas, ni siquiera necesita un nombre sintácticamente válido, sino que pude ser cualquier cadena de hasta 31 caracteres de longitud.
En algunas versiones previas de Postgres, name tenía que encerrarse entre comillas dobles cuando no había relación con ningún nombre de tabla existente, incluso si sintácticamente era válido como nombre. Esto ya no es necesario.
En versiones Postgres anteriores a la 6.4, el PID de backend repartido en un mensaje notify era siempre el PID del backend del frontend de uno mismo. Por eso no se podía distinguir las notificaciones deuno mismo de las notificaciones de otros clientes en aquellas versiones.