NOTIFY name |
Constate que la commande notify a été exécutée.
Les résultats sont transmis aux clients en attente; la façon dont réagit l'application cliente dépend de la façon dont elle a été programmée.
La commande NOTIFY envoie un résultat à chaque application cliente qui a précédemment exécuté LISTEN notifyname pour la condition de notification spécifiée dans la base.
L'information passée au client pour une condition de notification comprend le nom de la condition de notification et le PID du processus du serveur notifiant. Il appartient au designer de la base de définir les noms de condition qui seront utilisés dans la base et ce que chacun fait.
Couramment, le nom de condition de notification est le même que le nom de certaines tables de la base, et le résultat notify indique essentiellement "j'ai changé cette table, regarder ce qu'il y a de nouveau". Mais aucune association n'est mise en vigueur par les commandes NOTIFY et LISTEN. Par exemple, un database designer peut utiliser plusieurs noms différents de condition pour signaler diverses sortes de changement à une table unique.
NOTIFY fournit une forme de signal simple ou mécanisme IPC (interprocess communication) pour un ensemble de processus accédant à la même base Postgres. Des mécanismes de haut-niveau peuvent être construits en utilisant les tables dans une base pour transmettre des données supplémentaires (au delà d'un nom de condition unique) du notifiant au listener(s).
Quand NOTIFY est utilisé pour signaler l'occurence de changements d'une table particulière, une puissante technique de programmation est de placer NOTIFY dans une règle qui est déclanchée par la mise à jour des tables. De cette façon, la notification se produit automatiquement quand la table est modifiée, et le programmeur de l'application ne peut pas accidentellement oublier de le faire.
NOTIFY interagit avec les transactions SQL de plusieurs façons importantes. Premièrement, si un NOTIFY est exécuté à l'intérieur d'une transaction, les résultats de la notification ne sont pas délivrés jusqu'à ce que la transaction soit validée. Ceci est approprié, car si la transaction est annulée nous aimerions que toutes les commandes dans celle-ci n'aient pas d'effets --- y compris NOTIFY. Mais ce peut être déconcertant si une s'attend à ce que les résultats soient délivrés immédiatement. Deuxièmement, si un serveur en attente reçoit un signal de notification tandis qu'il est dans une transaction, les résultats de notification ne seront pas délivrés à son client connecté jusqu'à ce que la transaction soit complète (ou validée ou annulée). Encore, le raisonnement est que si un notify était délivré dans une transaction qui était plus tard avortée, on voudra que la notification soit défaite d'une façon ou d'une autre --- mais le serveur ne peut pas "take back" une notification une fois qu'il l'a envoyée au client. Ainsi les résultats d'une notification sont délivrés seulement entre les transactions. Le résultat de ceci est que les applications utilisant NOTIFY pour la signalisation en temps réel essaieront de conserver leurs transactions courtes.
NOTIFY se comporte comme les signaux Unix : si le même nom de condition est signalé plusieurs fois dans une succession rapide, les recipients peuvent obtenir seulement un résultat de notification pour plusieurs exécutions de NOTIFY. Ainsi c'est une mauvaise idée de dépendre du nombre de notifications reçues. Au lieu de ça, utiliser NOTIFY pour relancer des applications qui nécessitent to pay attention to something, et utiliser une base objet (comme une séquence) pour garder la trace de ce qui est survenu et combien de fois c'est survenu.
Il est habituel pour un client qui envoie un NOTIFY d'être en écoute sur le même nom de notification que lui-même. Dans ce cas, il renverra un résultat de notification, comme tous les autres clients en attente. En fonction de la logique de l'application, ceci peut être un travail inutile --- par exemple, relire une table de la base pour trouver les mêmes mises à jour que ce que le client vient juste d'écrire. Dans les versions 6.4 et plus récentes de Postgres, il est possible d'éviter ceci en noticing si le processus PID du serveur notifiant (envoyant le message de résultat de notification) est le même que son propre PID serveur (disponible depuis libpq). Quand ce sont les mêmes, le notify event is one's own work bouncing back, et peut être ignoré. (En dépit de ce qui a été dit dans le paragraphe précédent, c'est une technique sûre. Postgres conserve les self-notifies séparés des notifies des autres serveurs, ainsi vous ne pouvez pas oublier un outside notify en ignorant vos propres notifies).
name peut être une chaîne valide comme un nom; il n'a pas besoin de correspondre à un nom de table existant. Si name est inclu dans des guillemets, il n'a même pas besoin d'être un nom syntaxiquement valide, mais peut être une chaîne jusqu'à 31 caractères de long.
Dans certaines versions précédentes de Postgres, name était inclu entre guillemets quand il ne correspondait à aucun nom de table existant, même si le nom était syntaxiquement valide. Ce n'est plus nécessaire.
Dans les versions antérieures à 6.4 de Postgres le PID serveur délivré dans un message de notification était toujours le PID du client. Aussi il n'était pas possible de distinguer ses propres notifies de ceux des autres clients.