LISTEN in NOTIFY zagotavljata vgrajen sistem za publish/subscribe razmnoževanje sporočil v PostgreSQL-u — ena seja lahko pošlje obvestilo na kanalu, druge seje, ki poslušajo na tem kanalu, pa ga prejejo takoj. Gre za lahek način, kako iz baze podatkov potiskati dogodke v realnem času brez anketiranja.
LISTEN order_created;
NOTIFY order_created, ;
LISTEN se naroči na kanal; NOTIFY objavi na njem (z izbirno tekstovno vsebino). Poslušalci prejmejo obvestilo asinhrano — ni potrebno anketiranje.
-- 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
Združivanje NOTIFY s triggerjem omogoči, da baza podatkov samodejno potisne dogodke, ko se podatki spremenijo (nova naročila, posodobitev statusa) — strežniki aplikacij, ki poslušajo na kanalu, se nanj odzvejo v realnem času.
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 je uporabna, nekoliko manj znana funkcionalnost PostgreSQL-a, ki zagotavlja vgrajen pub/sub sistem za razmnoževanje sporočil, dragocen za dodajanje reaktivnosti v realnem času aplikacijam brez anketiranja.
Osrednja vrednost je sposobnost, da baza podatkov potisne dogodke do poslušalnih sej aplikacije takoj, ko se kaj zgodi (novo naročilo, sprememba statusa) — običajno v kombinaciji s triggeri, tako da spremembe podatkov samodejno obvestijo poslušalce, ki se aplikacijski strežniki odzvejo (potiskanje na websocket-e, razveljavitev predpomnilnikov, proženje ozadja dela).
To je dragoceno, ker omogoča obnašanje, ki ga poganja dogodke v realnem času, brez neučinkovitosti anketiranja baze podatkov po večkrat, da se preverijo spremembe (pogosta, neproduktivna praksa, ki jo LISTEN/NOTIFY elegantno nadomesti).
Razumevanje mehanizma (LISTEN za naročilo, NOTIFY za objavo, s triggeri za samodejno obvestilo ob spremembah podatkov) in kako ga aplikacije uporabljajo (poslušanje dogodkov za pogon reaktivnih odzivov v realnem času), je koristno za gradnjo odzivnih, aplikacij, ki jih poganjajo dogodki, z uporabo le PostgreSQL-a.
Enako važno je poznavanje omejitev: obvestila niso trajno shranjena (se izgubijo, če nihče ne sluša — brez jamstev za trajnost), imajo majhne količine podatkov in se sprožijo šele po potrdilu — zato je primerno za lahko signaliziranje v realnem času, ne za zameno trajnega posrednika sporočil (RabbitMQ, Kafka), ko sta zanesljivost in trajnost povezane.
Ker je reaktivnost v realnem času pogosta potreba in LISTEN/NOTIFY ponuja vgrajen, anketiranju prost način za njeno dosego v lahkih primerih, je razumevanje tega — mehanizem pub/sub, vzorec triggerja in kritično njegove omejitve (kdaj je primeren za uporabo in kdaj je potreben pravi posrednik) — dragoceno, praktično relevantno znanje PostgreSQL-a za gradnjo aplikacij, ki jih poganjajo dogodki, uporabna vgrajena funkcionalnost, ki se jo pogosto spregledamo.