LISTEN și NOTIFY oferă un sistem de mesagerie publish/subscribe încorporat în PostgreSQL — o sesiune poate trimite o notificare pe un canal, și alte sesiuni care ascultă pe acel canal o primesc instantaneu. Este o modalitate ușoară de a propaga événimente în timp real din bază de date fără polling.
LISTEN order_created;
NOTIFY order_created, ;
LISTEN se abonează la un canal; NOTIFY publică pe el (cu un payload text opțional). Ascultătorii sunt notificați asincron — nu este necesar polling.
-- 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
Combinarea NOTIFY cu un trigger permite bazei de date să propage automat événimente atunci când datele se modifică (comandă nouă, actualizare stare) — serverele de aplicație care ascultă pe canal reacționează în timp real.
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 este o caracteristică PostgreSQL utilă, oarecum mai puțin cunoscută, care oferă mesagerie pub/sub încorporată, valoroasă pentru adăugarea reactivității în timp real la aplicații fără polling.
Valoarea esențială constă în a permite bazei de date să propage evenimente către sesiunile de aplicație care ascultă instantaneu atunci când ceva se întâmplă (o comandă nouă, o schimbare de stare) — tipic combinată cu triggere pentru ca modificările de date să notifice automat ascultătorii, la care serverele de aplicație reacționează (prin push la websockets, invalidare cache, declanșare muncă în fundal).
Aceasta este valoroasă pentru că oferă comportament condus de evenimente în timp real fără ineficiența polling-ului bazei de date în mod repetat pentru a verifica dacă au apărut schimbări (un pattern frecvent și risipitor pe care LISTEN/NOTIFY îl înlocuiește elegant).
Înțelegerea mecanismului (LISTEN pentru a se abona, NOTIFY pentru a publica, cu triggere pentru notificare automată la modificări de date) și modul în care o folosesc aplicațiile (ascultarea evenimentelor pentru a determina reacții în timp real) este utilă pentru construirea aplicațiilor responsabile și conduse de evenimente folosind doar PostgreSQL.
La fel de important este cunoașterea limitărilor: notificările nu sunt persistate (se pierd dacă nimeni nu ascultă — fără garanții de durabilitate), au payload-uri mici și se declanșează doar după commit — deci este potrivită pentru semnalizare ușoară în timp real, nu pentru înlocuirea unui message broker durabil (RabbitMQ, Kafka) atunci când fiabilitatea și persistența sunt importante.
Deoarece reactivitatea în timp real este o nevoie frecventă și LISTEN/NOTIFY oferă o modalitate încorporată, fără polling, de a o realiza pentru cazuri ușoare, înțelegerea ei — mecanismul pub/sub, pattern-ul trigger, și în mod crucial limitările ei (când este suficientă vs când este necesar un broker real) — este cunoaștere PostgreSQL valoroasă și practic relevantă pentru construirea aplicațiilor conduse de evenimente, o caracteristică încorporată utilă care este adesea trecută cu vederea.