LISTEN i NOTIFY zapewniają wbudowany system obsługi wiadomości publish/subscribe w PostgreSQL — jedna sesja może wysłać powiadomienie na kanale, a inne sesje nasłuchujące tego kanału otrzymają je natychmiast. To lekki sposób na push zdarzeń w czasie rzeczywistym z bazy danych bez potrzeby polowania.
LISTEN order_created;
NOTIFY order_created, ;
LISTEN subskrybuje kanał; NOTIFY publikuje na nim (z opcjonalnym paylodem tekstowym). Słuchacze otrzymują powiadomienia asynchronicznie — nie jest potrzebne polowanie.
-- 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
Połączenie NOTIFY z triggerem pozwala bazie danych automatycznie push'ować zdarzenia, gdy dane się zmieniają (nowe zamówienie, aktualizacja statusu) — serwery aplikacji nasłuchujące kanału reagują w czasie rzeczywistym.
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 to przydatna, nieco mniej znana funkcja PostgreSQL, która zapewnia wbudowaną obsługę pub/sub, wartościowa do dodania reaktywności w czasie rzeczywistym do aplikacji bez polowania.
Główna wartość to umożliwienie bazie danych push'owania zdarzeń do nasłuchujących sesji aplikacji natychmiast, gdy coś się stanie (nowe zamówienie, zmiana statusu) — zazwyczaj łączone z triggerami, aby zmiany danych automatycznie powiadamiały słuchaczy, na co serwery aplikacji reagują (push do websocket'ów, unieważnianie cache'u, uruchamianie pracy w tle).
Jest to wartościowe, ponieważ zapewnia zachowanie sterowane zdarzeniami w czasie rzeczywistym bez nieefektywności polowania bazy danych wielokrotnie w celu sprawdzenia zmian (powszechny, marnotrawny wzorzec, który LISTEN/NOTIFY elegancko zastępuje).
Zrozumienie mechanizmu (LISTEN do subskrypcji, NOTIFY do publikacji, z triggerami dla automatycznego powiadamiania przy zmianach danych) i jak aplikacje go używają (nasłuchiwanie zdarzeń do napędzania reaktywnych akcji w czasie rzeczywistym) jest przydatne do budowania responsywnych, sterowanych zdarzeniami aplikacji używających tylko PostgreSQL.
Również ważne jest znanie ograniczeń: powiadomienia nie są utrwalane (zginają jeśli nikt nie nasłuchuje — brak gwarancji trwałości), mają małe payload'i i uruchamiają się tylko po commit'cie — więc nadają się do lekkich sygnałów w czasie rzeczywistym, nie będąc zamiennikiem trwałego brokera wiadomości (RabbitMQ, Kafka), gdy ważne są niezawodność i trwałość.
Ponieważ reaktywność w czasie rzeczywistym jest powszechną potrzebą, a LISTEN/NOTIFY oferuje wbudowany, wolny od polowania sposób na jej osiągnięcie w lekkich przypadkach, zrozumienie go — mechanizmu pub/sub, wzorca trigger'a i kluczowo jego ograniczeń (kiedy wystarczy vs kiedy potrzebny jest rzeczywisty broker) — jest wartościową, praktycznie istotną wiedzą PostgreSQL do budowania aplikacji sterowanych zdarzeniami, przydatną wbudowaną funkcją, która jest często pomijana.