NOTIFY nom
La commande NOTIFY envoie une notification à chaque application cliente qui a exécuté précédemment la commande LISTEN nom dans la base de données courante pour le nom de notification indiqué.
NOTIFY fournit une forme simple de signal ou de mécanisme de communication interprocessus pour tout ensemble de processus accédant à la même base de données PostgreSQL™. Des mécanismes de plus haut niveau peuvent être construits en utilisant les tables de la base de données pour passer des données supplémentaires (au-delà du simple nom de notification) du notifieur aux écouteurs.
L'information passée au client pour une notification inclut le nom de la notification et le PID du processus serveur de la session le notifiant. C'est au concepteur de la base de données de définir les noms de notification utilisés dans une base de données précise et la signification de chacun.
Habituellement, le nom de notification correspond au nom d'une table dans la base de données. L'événement notify signifie essentiellement « J'ai modifié cette table, jetez-y un œil pour vérifier ce qu'il y a de nouveau ». Mais cette association n'est pas contrôlée par les commandes NOTIFY et LISTEN. Un concepteur de bases de données peut, par exemple, utiliser plusieurs noms de notification différents pour signaler différentes sortes de modifications au sein d'une même table.
Lorsque NOTIFY est utilisé pour signaler des modifications sur une table particulière, une technique de programmation utile est de placer le NOTIFY dans une règle déclenchée par les mises à jour de la table. De cette façon, la notification est automatique lors d'une modification de la table et le programmeur de l'application ne peut accidentellement oublier de le faire.
NOTIFY interagit fortement avec les transactions SQL. Primo, si un NOTIFY est exécuté à l'intérieur d'une transaction, les événements notify ne sont pas délivrés avant que la transaction ne soit validée, et à cette condition uniquement. En effet, si la transaction est annulée, les commandes qu'elle contient n'ont aucun effet, y compris NOTIFY. Cela peut toutefois s'avérer déconcertant pour quiconque s'attend à une délivrance immédiate des notifications.
Secondo, si une session à l'écoute reçoit un signal de notification alors qu'une transaction y est active, la notification n'est pas délivrée au client connecté avant la fin de cette transaction (par validation ou annulation). Là encore, si une notification est délivrée à l'intérieur d'une transaction finalement annulée, on pourrait espérer annuler cette notification par quelque moyen -- mais le serveur ne peut pas « reprendre » une notification déjà envoyée au client. C'est pourquoi les notifications ne sont délivrés qu'entre les transactions. Il est, de ce fait, important que les applications qui utilisent NOTIFY pour l'envoi de signaux en temps réel conservent des transactions courtes.
NOTIFY se comporte comme les signaux Unix sur un point important : si le même nom de notification est signalé successivement et rapidement plusieurs fois, les récepteurs peuvent ne recevoir qu'un unique événement de notification pour plusieurs exécutions de NOTIFY. Il est donc malhabile de dépendre du nombre de notifications reçues. À la place, NOTIFY peut être utilisé pour réveiller les applications qui doivent être averties d'un évènement et un objet de bases de données (tel une séquence) utilisé pour garder une trace de ce qui s'est passé ou du nombre de fois que cela s'est produit.
Il est courant qu'un client qui exécute NOTIFY écoute lui-même des notifications de même nom. Dans ce cas, il récupère une notification, comme toutes les autres sessions en écoute. Suivant la logique de l'application, cela peut engendre un travail inutile, par exemple lire une table de la base de données pour trouver les mises à jour que cette session a elle-même écrites. Il est possible d'éviter ce travail supplémentaire en verifiant si le PID du processus serveur de la session notifiante (fourni dans le message d'événement de la notification) est le même que le PID de la session courante (disponible à partir de libpq). S'ils sont identiques, la notification est le retour du travail actuel et peut être ignorée. (En dépit de ce qui est dit dans le paragraphe qui précède, cette technique est sûre. PostgreSQL™ distingue les notifications propres des notifications en provenance d'autres sessions ; il n'y a donc aucun risque de passer à côté d'une notification externe lorsque les notifications propres sont ignorées.)
MOVE