O comando NOTIFY envia um evento de notificação para cada aplicativo cliente que tenha executado anteriormente o comando LISTEN nome_da_notificação para a condição de notificação especificada, no banco de dados corrente.
A notificação passada para o cliente por um evento de notificação inclui o nome da condição de notificação e o PID do processo servidor que está notificando. Fica por conta do projetista do banco de dados definir os nomes das condições que serão utilizadas em um determinado banco de dados e o significado de cada uma.
Usualmente, o nome da condição de notificação é o mesmo nome de uma tabela do banco de dados, e o evento de notificação essencialmente diz "Eu modifiquei a 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, o projetista do banco de dados pode usar vários nomes diferentes de condição para sinalizar diferentes tipos de mudança em uma única tabela.
O comando NOTIFY fornece uma forma de sinal simples, ou mecanismo de IPC (comunicação entre processos), para um conjunto de processos acessando o mesmo banco de dados do PostgreSQL. Mecanismos de nível mais alto podem ser construídos usando-se tabelas no banco de dados para passar informações adicionais (além do mero nome da condição) do notificador para o(s) ouvinte(s).
Quando o NOTIFY é utilizado para sinalizar a ocorrência de mudanças em uma tabela em particular, uma técnica de programação útil é colocar o NOTIFY em uma regra que é disparada pela atualização da tabela. Deste modo, a notificação acontece automaticamente quando a tabela é modificada, e o programador do aplicativo não vai poder acidentalmente esquecer de fazê-la.
O NOTIFY interage com as transações SQL de forma importante. Em primeiro lugar, se um NOTIFY for executado de dentro de uma transação, o evento de notificação não é enviado até que, e a menos que, a transação seja efetivada. Isto é apropriado porque, se a transação for abortada, deseja-se que nenhum de seus comandos tenha surtido efeito, incluindo o NOTIFY. Mas isto pode ser desconcertante se for esperado que os eventos de notificação sejam enviados imediatamente. Em segundo lugar, se um processo servidor na escuta recebe um sinal de notificação enquanto está executando uma transação, o evento de notificação não será enviado ao cliente conectado antes da transação ser completada (seja efetivada ou abortada). Novamente o raciocínio é que se a notificação for enviada de dentro de uma transação que for abortada posteriormente, vai se desejar que a notificação seja desfeita de alguma maneira --- mas o processo servidor não pode "pegar de volta" uma notificação após enviá-la para o cliente. Portanto, os eventos de notificação somente são enviados entre transações. O resultado final disto é que os aplicativos que utilizam o NOTIFY para sinalização de tempo real devem tentar manter as suas transações curtas.
O NOTIFY se comporta como os sinais do Unix em um aspecto importante: se o mesmo nome de condição for sinalizado diversas vezes em uma sucessão rápida, os ouvintes podem receber somente um evento de notificação para várias execuções do NOTIFY. Portanto, é uma má idéia depender do número de notificações recebidas. Em vez disso, use o NOTIFY para acordar os aplicativos que devam prestar atenção em algo, e use um objeto do banco de dados (como uma seqüência) para registrar o que aconteceu ou quantas vezes aconteceu.
É comum para um cliente que executa o NOTIFY estar escutando o mesmo nome de notificação. Neste caso vai ser recebido de volta o evento de notificação da mesma maneira que todos os outros clientes na escuta. Dependendo da lógica do aplicativo, isto pode resultar em um trabalho sem utilidade --- por exemplo, a releitura da tabela do banco de dados para encontrar as mesmas atualizações que foram feitas. No PostgreSQL 6.4, e nas versões posteriores, é possível evitar este trabalho extra verificando se o PID do processo servidor que fez a notificação (fornecido na mensagem do evento de notificação) é o mesmo PID do seu processo servidor (disponível pela libpq). Quando forem idênticos, o evento de notificação é o seu próprio trabalho retornando, podendo ser ignorado (A despeito do que foi dito no parágrafo precedente, esta é uma técnica segura. O PostgreSQL mantém as auto-notificações separadas das notificações vindas de outros processos servidores, portanto não é possível perder-se uma notificação externa ignorando-se as próprias notificações).
nome pode ser qualquer cadeia de caracteres válida como um nome; não é necessário que corresponda ao nome de qualquer tabela existente. Se nome estiver entre aspas ("), não é necessário nem que seja um nome com uma sintaxe válida; pode ser qualquer cadeia de caracteres com até 31 caracteres.
Em algumas versões anteriores do PostgreSQL, o nome tinha que vir entre aspas quando não correspondia a nenhum nome de tabela existente, mesmo que sintaticamente fosse um nome válido, mas não é mais necessário.
Nas versões do PostgreSQL anteriores a 6.4, o PID do processo servidor que enviou a mensagem de notificação era sempre o PID do processo servidor do próprio cliente. Então não era possível distinguir entre as próprias notificações e as notificações dos outros clientes nestas versões antigas.