LISTEN og NOTIFY giver et indbygget publish/subscribe messaging-system i PostgreSQL — én session kan sende en notifikation på en kanal, og andre sessioner, der lytter på den kanal, modtager den øjeblikkeligt. Det er en letvægts måde at pushe real-time events fra databasen uden polling.
LISTEN order_created;
NOTIFY order_created, ;
LISTEN abonnerer på en kanal; NOTIFY publicerer til den (med en valgfri tekstpayload). Listeners får notificering asynkront — ingen polling nødvendig.
-- a trigger that notifies whenever a row is inserted
CREATE FUNCTION notify_new_order() RETURNS trigger AS $$
BEGIN
PERFORM pg_notify('order_created', NEW.id::text); -- notify with the new id
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
CREATE TRIGGER order_notify AFTER INSERT ON orders
FOR EACH ROW EXECUTE FUNCTION notify_new_order();
-- now inserting an order automatically pushes a notification to listeners
Når du kombinerer NOTIFY med en trigger, kan databasen automatisk pushe events, når data ændres (ny ordre, statusopdatering) — application servers, der lytter på kanalen, reagerer i realtid.
Application code (Node, Python, etc.) opens a connection and LISTENs on a channel.
When a NOTIFY fires (e.g. from a trigger on data change), the app receives the event
and reacts — pushing to websockets, invalidating a cache, triggering a job, etc.
→ Real-time reactions to database changes WITHOUT polling the database.
✗ Notifications are NOT persisted — if no one is listening, the message is LOST
(no durability/queue guarantees like a real message broker)
✗ Payload is small (limited size); delivered only after the transaction COMMITS
→ Good for lightweight real-time signaling; for durable/reliable messaging use a
proper broker (RabbitMQ, Kafka) or a queue table.
LISTEN/NOTIFY er en brugbar, noget mindre kendt PostgreSQL-feature, der giver indbygget pub/sub messaging, værdifuldt til at tilføje real-time reaktivitet til applikationer uden polling.
Kernværdien er at gøre det muligt for databasen at pushe events til lyttende applikations-sessioner øjeblikkeligt, når noget sker (en ny ordre, en statusændring) — typisk kombineret med triggers, så dataændringer automatisk notificerer listeners, som applikations-servere reagerer på (pusher til websockets, invaliderer caches, udløser baggrundsjob).
Dette er værdifuldt, fordi det giver real-time event-drevet adfærd uden ineffektiviteten ved at loope databasen gentagne gange for at kontrollere ændringer (et almindeligt, spildende mønster, som LISTEN/NOTIFY elegant erstattar).
At forstå mekanismen (LISTEN for at abonnere, NOTIFY for at publicere, med triggers for automatisk notificering ved dataændringer) og hvordan applikationer bruger det (at lytte efter events for at drive real-time reaktioner) er brugbart til at bygge responsive, event-drevet applikationer ved kun at bruge PostgreSQL.
Ligeledes vigtig er det at kende begrænsningerne: notifikationer er ikke persisteret (går tabt, hvis ingen lytter — ingen holdbarhedsgarantier), har små payloads, og udløses kun efter commit — så det er egnet til letvægts real-time signalering, ikke en erstatning for en holdbar message broker (RabbitMQ, Kafka), når pålidelighed og persistering betyder noget.
Da real-time reaktivitet er et almindeligt behov, og LISTEN/NOTIFY tilbyder en indbygget, polling-fri måde at opnå det for letvægts tilfælde, er det værdifuldt at forstå det — pub/sub-mekanismen, trigger-mønsteret, og afgørende dets begrænsninger (når det er tilstrækkeligt versus når en rigtig broker er nødvendig) — værdifuld, praktisk relevant PostgreSQL-viden til at bygge event-drevet applikationer, en brugbar indbygget feature, der ofte bliver overset.