LISTEN og NOTIFY gir et innebygd publish/subscribe-meldingssystem i PostgreSQL — en sesjon kan sende en melding på en kanal, og andre sesjoner som lytter på den kanalen mottar den øyeblikkelig. Det er en lettvekt måte å skyve sanntidshendelser fra databasen uten polling.
LISTEN order_created;
NOTIFY order_created, ;
LISTEN abonnerer på en kanal; NOTIFY publiserer til den (med en valgfri tekstnyttelast). Lyttere varsles 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
Kombinasjon av NOTIFY med en trigger lar databasen automatisk skyve hendelser når data endres (ny ordre, statusoppdatering) — applikasjonstjenere som lytter på kanalen reagerer i sanntid.
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 nyttig, noe mindre kjent PostgreSQL-funksjon som gir innebygd pub/sub-meldinger, verdifull for å legge til sanntidsreaktivitet til applikasjoner uten polling.
Kjernenverdien er å gjøre det mulig for databasen å skyve hendelser til lyttende applikasjonssesjoner øyeblikkelig når noe skjer (en ny ordre, en statusendring) — typisk kombinert med triggers slik at dataendringer automatisk varsler lyttere, som applikasjonstjenere reagerer på (skyver til websockets, invaliderer cacher, utløser bakgrunnsarbeid).
Dette er verdifull fordi det gir sanntidshendelsesorientert oppførsel uten ineffektiviteten ved å polls databasen gjentatte ganger for å kontrollere for endringer (et vanlig, sløseri mønster som LISTEN/NOTIFY elegant erstatter).
Å forstå mekanismen (LISTEN for å abonnere, NOTIFY for å publisere, med triggers for automatisk varsling ved dataendringer) og hvordan applikasjoner bruker det (lytting etter hendelser for å drive sanntidsreaksjoner) er nyttig for å bygge responsive, hendelsesorienterte applikasjoner ved kun å bruke PostgreSQL.
Like viktig er å kjenne til begrensningene: varslinger er ikke vedvarende (går tapt hvis ingen lytter — ingen varighetsgarantier), har små nyttelaster, og avfyres kun etter commit — så det passer til lett sanntidssignalisering, ikke en erstatning for en varig meldingsmegler (RabbitMQ, Kafka) når pålitelighet og vedholdenhet betyr noe.
Fordi sanntidsreaktivitet er et vanlig behov og LISTEN/NOTIFY tilbyr en innebygd, polling-fri måte å oppnå det for lettvekttilfeller, er det verdifult å forstå det — pub/sub-mekanismen, triggermønsteret, og avgjørende dets begrensninger (når det holder vs når en ekte megler er nødvendig) — praktisk relevant PostgreSQL-kunnskap for å bygge hendelsesorienterte applikasjoner, en nyttig innebygd funksjon som ofte blir oversett.