LISTEN e NOTIFY forniscono un sistema di messaggistica publish/subscribe integrato in PostgreSQL — una sessione può inviare una notifica su un canale e altre sessioni in ascolto su quel canale la ricevono istantaneamente. È un modo leggero per spingere eventi in tempo reale dal database senza polling.
LISTEN order_created;
NOTIFY order_created, ;
LISTEN si iscrive a un canale; NOTIFY pubblica su di esso (con un payload di testo opzionale). I listener vengono notificati in modo asincrono — nessun polling necessario.
-- 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
Combinare NOTIFY con un trigger consente al database di spingere automaticamente eventi quando i dati cambiano (nuovo ordine, aggiornamento dello stato) — i server applicativi in ascolto sul canale reagiscono in tempo reale.
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 è una feature utile, un po' meno conosciuta, di PostgreSQL che fornisce messaggistica pub/sub integrata, preziosa per aggiungere reattività in tempo reale alle applicazioni senza polling.
Il valore principale è consentire al database di spingere eventi alle sessioni applicative in ascolto istantaneamente quando accade qualcosa (un nuovo ordine, un cambio di stato) — tipicamente combinato con trigger in modo che i cambiamenti di dati notifichino automaticamente i listener, a cui i server applicativi reagiscono (spingendo a websocket, invalidando cache, attivando lavori in background).
Questo è prezioso perché fornisce comportamento event-driven in tempo reale senza l'inefficienza del polling ripetuto del database per verificare i cambiamenti (un pattern comune e dispendioso che LISTEN/NOTIFY sostituisce elegantemente).
Comprendere il meccanismo (LISTEN per iscriversi, NOTIFY per pubblicare, con trigger per la notifica automatica sui cambiamenti di dati) e come le applicazioni lo usano (ascoltare gli eventi per guidare reazioni in tempo reale) è utile per costruire applicazioni responsabili e event-driven utilizzando solo PostgreSQL.
Egualmente importante è conoscere le limitazioni: le notifiche non sono persistite (perse se nessuno è in ascolto — nessuna garanzia di durabilità), hanno payload piccoli e si attivano solo dopo il commit — quindi è adatto alla segnalazione leggera in tempo reale, non a un sostituto di un message broker durevole (RabbitMQ, Kafka) quando affidabilità e persistenza contano.
Poiché la reattività in tempo reale è un'esigenza comune e LISTEN/NOTIFY offre un modo integrato e senza polling per raggiungerla nei casi leggeri, comprenderlo — il meccanismo pub/sub, il pattern trigger e crucialmente le sue limitazioni (quando è sufficiente rispetto a quando serve un broker vero) — è una conoscenza PostgreSQL preziosa e praticamente rilevante per costruire applicazioni event-driven, una feature integrata utile spesso trascurata.