O comando NOTIFY envia um evento de notificação para todos os aplicativos cliente que executaram anteriormente o comando LISTEN nome para o nome de notificação especificado no banco de dados corrente.
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).
A informação passada para o cliente pelo 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 é imposta pelos comandos NOTIFY e LISTEN. Por exemplo, o projetista de banco de dados pode usar vários nomes de notificação diferentes para sinalizar diferentes tipos de mudança em uma única tabela.
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 do aplicativo 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 os eventos de notificação não serão enviados até que, e a não ser 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 causar confusão 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 (tanto efetivada quanto interrompida). Novamente o raciocínio é: se a notificação for entregue dentro de uma transação interrompida posteriormente, também se deseja que a notificação seja desfeita de alguma forma — 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, os aplicativos 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 poderão 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 os aplicativos que devem prestar atenção em alguma coisa, e usado um objeto de banco de dados (como uma seqüência) para acompanhar o que aconteceu, ou quantas vezes aconteceu.
É comum a situação onde o cliente que executa o comando NOTIFY está ouvindo 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 do aplicativo, 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 ouvir/notificar a partir do psql:
LISTEN virtual; NOTIFY virtual; Notificação assíncrona "virtual" recebida do processo servidor com PID 5438.
