Co jsou LISTEN a NOTIFY?

Question

Accepted Answer

**`LISTEN`** a **`NOTIFY`** poskytují vestavěný systém **publish/subscribe** zasílání zpráv v PostgreSQL — jedna relace může poslat notifikaci na kanál a ostatní relace naslouchající na tomto kanálu ji obdrží okamžitě. Je to lehký způsob, jak tlačit real-time události z databáze bez poolování.

## Základní mechanismus

```sql
-- a session SUBSCRIBES to a channel
LISTEN order_created;

-- another session/transaction PUBLISHES a notification (with an optional payload)
NOTIFY order_created, 'order id 123';
-- → all sessions listening on 'order_created' receive the message immediately
```

LISTEN se přihlašuje k kanálu; NOTIFY do něj publikuje (s volitelnou textovou zprávou). Naslouchači jsou notifikováni asynchronně — není potřeba poolování.

## Automatické spouštění NOTIFY (běžný vzor)

```sql
-- 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
```

Skombinování NOTIFY s **triggery** umožňuje databázi automaticky tlačit události, když se data změní (nová objednávka, aktualizace stavu) — aplikační servery naslouchající na kanálu reagují v reálném čase.

## Jak aplikace to používají

```text
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.
```

## Omezení, která byste měli znát

```text
✗ 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.
```

## Proč je to důležité

`LISTEN`/`NOTIFY` je užitečná, poměrně méně známá funkcionalita PostgreSQL, která poskytuje **vestavěné pub/sub zasílání zpráv**, cenné pro přidání **real-time reaktivity** do aplikací bez poolování.

Jádrem hodnoty je schopnost databáze **tlačit události** okamžitě do naslouchajících aplikačních relací, když se něco stane (nová objednávka, změna stavu) — typicky kombinováno s **triggery**, takže změny dat automaticky notifikují naslouchače, na které aplikační servery reagují (push do websocketů, zneplatnění cache, spuštění na pozadí běžící práce).

Toto je cenné, protože poskytuje chování řízené událostmi v reálném čase bez neefektivity **poolování** databáze opakovaně pro kontrolu změn (běžný, plýtvavý vzor, který LISTEN/NOTIFY elegantně nahrazuje).

Porozumění mechanismu (LISTEN pro přihlášení, NOTIFY pro publikování, s triggery pro automatickou notifikaci při změnách dat) a způsobu, jak ho aplikace používají (naslouchání událostem pro řízení real-time reakcí), je užitečné pro vytváření responsivních, event-driven aplikací pouze pomocí PostgreSQL.

Rovněž důležité je znát **omezení**: notifikace **nejsou uchován** (ztraceny, pokud nikdo nenaslouchá — žádné záruky trvanlivosti), mají malé zátěže a spouštějí se pouze po commit — takže je vhodné pro lehké real-time signalizování, *ne* jako náhrada trvanlivého message brokeru (RabbitMQ, Kafka), když je důležitá spolehlivost a perzistence.

Protože real-time reaktivity je běžná potřeba a LISTEN/NOTIFY nabízí vestavěný, bez-poolovací způsob, jak ji dosáhnout pro lehké případy, porozumění — pub/sub mechanismu, vzoru s triggery a zejména jeho omezením (kdy stačí vs kdy je potřeba skutečný broker) — je cenné, prakticky relevantní PostgreSQL znalosti pro vytváření event-driven aplikací, užitečná vestavěná funkcionalita, která je často přehlížena.