O comando NOTIFY envia um evento de notificação para todas as aplicações cliente, que tenham executado anteriormente o comando LISTEN nome para o nome de notificação especificado, no banco de dados corrente,.
A informação passada para o cliente por um evento de notificação inclui o nome da notificação e o PID do processo servidor da sessão notificadora. É função do projetista do banco de dados definir os nomes das notificações a serem utilizadas em um determinado banco de dados, e o significado de cada uma delas.
Usualmente, o nome da notificação é o mesmo de alguma tabela do banco de dados, e o evento de notificação essencialmente diz "Eu modifiquei esta tabela, dê uma olhada nela e veja o que há de novo". Porém, este tipo de associação não é exigida pelos comandos NOTIFY e LISTEN. Por exemplo, um projetista de banco de dados pode usar vários nomes diferentes de notificação para sinalizar diferentes tipos de mudança em uma única tabela.
O comando NOTIFY fornece uma forma de sinal simples, ou mecanismo de comunicação entre processos, para um conjunto de processos que acessam o mesmo banco de dados do PostgreSQL. Podem ser construídos mecanismos de mais alto nível usando tabelas do banco de dados para passar dados adicionais do notificador para os ouvintes (além do mero nome da notificação).
Quando o comando NOTIFY é utilizado para sinalizar a ocorrência de mudanças em uma determinada tabela, uma técnica de programação útil é colocar o comando NOTIFY na regra disparada pela atualização da tabela. Assim, a notificação acontece automaticamente quando a tabela é modificada, e o programador da aplicação não pode acidentalmente esquecer de enviá-la.
O comando NOTIFY interage com as transações SQL de maneiras importantes. Em primeiro lugar, se o comando NOTIFY for executado dentro de uma transação o evento de notificação não será enviado até que, e a menos que, a transação seja efetivada. Este comportamento é apropriado, porque se a transação for interrompida todos os comandos dentro desta serão sem efeito, incluindo o NOTIFY. Mas, por outro lado, pode ser desconcertante quando se espera que os eventos de notificação sejam enviados imediatamente. Em segundo lugar, se a sessão ouvinte receber um sinal de notificação durante o tempo em que está executando uma transação, o evento de notificação não será entregue ao seu cliente conectado antes que a transação esteja completa (seja efetivada ou interrompida). Novamente o raciocínio é: se a notificação for enviada dentro de uma transação interrompida posteriormente, se deseja que a notificação seja desfeita de alguma maneira — mas o servidor não pode "pegar de volta" uma notificação após tê-la enviado para o cliente. Portanto, os eventos de notificação somente são entregues entre transações. O resultado final desta situação é que, as aplicações que utilizam o comando NOTIFY para sinalização em tempo real devem tentar manter suas transações curtas.
O comando NOTIFY se comporta como os sinais do Unix sob um aspecto importante: se o mesmo nome de notificação for sinalizado diversas vezes em uma sucessão rápida, os receptores podem receber somente um evento de notificação para várias execuções do comando NOTIFY. Portanto, é uma má idéia depender do número de notificações recebidas. Em vez disso, deve ser utilizado o comando NOTIFY para acordar as aplicações que devem prestar atenção em alguma coisa, e usado um objeto de banco de dados (como uma seqüência) para ter conhecimento do que aconteceu, ou quantas vezes aconteceu.
É comum a situação onde o cliente que executa o comando NOTIFY está escutando este nome de notificação. Neste caso, este cliente recebe o evento de notificação da mesma forma que todas as outras sessões ouvintes. Dependendo da lógica da aplicação, pode resultar em um trabalho sem utilidade; por exemplo, ler a tabela do banco de dados para encontrar as mesmas atualizações que esta sessão acabou de fazer. É possível evitar este trabalho adicional verificando se o PID do processo servidor da sessão notificadora (presente na mensagem do evento de notificação) é o mesmo PID da própria sessão (disponível pela libpq). Quando forem idênticos, o evento de notificação é o seu próprio trabalho retornando, podendo ser ignorado (Apesar do que foi dito no parágrafo anterior, esta técnica é segura. O PostgreSQL mantém as autonotificações separadas das notificações vindas de outras sessões e, portanto, não é possível perder uma notificação externa ignorando as próprias notificações).
Configurar e executar a seqüência escutar/notificar usando a aplicação psql:
=> LISTEN virtual; => NOTIFY virtual; Asynchronous notification "virtual" received from server process with PID 8448.