Description

LISTEN enregistre la session courante comme listener du canal de notification canal. Si la session courante est déjà enregistrée comme listener de ce canal de notification, il ne se passe rien de plus.

À chaque appel de la commande NOTIFY canal, que ce soit par cette session ou par une autre connectée à la même base de données, toutes les sessions attendant sur ce canal en sont avisées et chacune en avise en retour son client. Voir NOTIFY pour plus d'informations.

La commande UNLISTEN permet d'annuler l'enregistrement d'une session comme listener d'un canal de notification. Les enregistrements d'écoute d'une session sont automatiquement effacés lorsque la session se termine.

La méthode utilisé par un client pour détecter les événements de notification dépend de l'interface de programmation PostgreSQL qu'il utilise. Avec la bibliothèque libpq, l'application exécute LISTEN comme une commande SQL ordinaire, puis appelle périodiquement la fonction PQnotifies pour savoir si un événement de notification est reçu. Les autres interfaces, telle libpgtcl, fournissent des méthodes de plus haut niveau pour gérer les événements de notification ; en fait, avec libpgtcl, le développeur de l'application n'a même pas à lancer LISTEN ou UNLISTEN directement. Tous les détails se trouvent dans la documentation de l'interface utilisée.

Paramètres

Notes

LISTEN prend effet à la validation de la transaction. Si LISTEN ou UNLISTEN est exécuté dans une transaction qui sera ensuite annulée, l'ensemble des canaux de notification écoutés sera inchangé.

Une transaction qui a exécuté LISTEN ne peut pas être préparée pour la validation en deux phases.

Il existe une fenêtre de vulnérabilité lors de la mise en place d'une session d'écoute : si des transactions validant en concurrence envoient des notifications, quels sont celles que la nouvelle session en écoute va recevoir ? La réponse est que la session recevra tous les événements validés après un instant lors de l'étape de validation de la transaction. Mais c'est légèrement plus tard que n'importe quel état de base de données qu'aurait pu observer une transaction avec des requêtes. Cela conduit à la règle suivante pour l'utilisation de LISTEN : exécutez d'abord (et validez !) cette commande, puis dans une nouvelle transaction, inspectez l'état de la base de données selon les besoins de la logique de l'application. Ensuite, utilisez les notifications pour connaître les modifications ultérieures de l'état de la base de données. Les premières notifications reçues peuvent faire référence à des mises à jour déjà constatées lors de l'inspection initiale de la base de données, mais cela est généralement sans conséquence.

NOTIFY contient une discussion plus étendue sur l'utilisation de LISTEN et NOTIFY.

Exemples

Configurer et exécuter une séquence listen/notify à partir de psql :

LISTEN virtual;
NOTIFY virtual;
Notification asynchrone "virtual" reçue en provenance du processus serveur de PID 8448.
   

Compatibilité

Il n'existe pas d'instruction LISTEN dans le standard SQL.

Voir aussi