Documentation PostgreSQL 15.15 » Référence » Commandes SQL » LISTEN

Précédent | Niveau supérieur | Suivant
INSERT | Sommaire | LOAD

## LISTEN

LISTEN — Attendre une notification

## Synopsis

    LISTEN canal

## 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

`canal`

  Le nom d'un canal de notification (tout identifiant).

## 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

NOTIFY, UNLISTEN