LISTEN u NOTIFY jipprovdu sistema publish/subscribe li jinqiegħa fil-PostgreSQL — sessjoni waħda tista' tibgħat notifika fuq kanal, u sessjonijiet oħrajn li jistgħu jismacu fuq dak il-kanal jirċivuha immedjatament. Huwa mod ħafif biex tpinġi avvenimenti real-time mit-database mingħajr polling.
LISTEN order_created;
NOTIFY order_created, ;
LISTEN jissottoskriva għal kanal; NOTIFY jippubblika għalih (bi payload ta' test fakultativi). Il-listeners jirċivuh n-notifika asinkrinikament — m'hemm l-ebda polling meħtieġ.
-- 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
Il-kombinazzjoni ta' NOTIFY ma' trigger tippermetti lid-database jawtomatikament ipinġi avvenimenti meta d-data tinbidel (ordni ġdid, aġġornament tal-istat) — server tal-applikazzjoni li jismacu fuq il-kanal jrieggaċu b'mod real-time.
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 hija feature utli, daqsbih mhux magħrufa sew, ta' PostgreSQL li jipprovdu built-in pub/sub messaging, ta' valur għal iż-żieda ta' real-time reactivity lill-applikazzjonijiet mingħajr polling.
Il-valur ewwel huwa li jippermettu lid-database ipinġi avvenimenti lill-sessjonijiet tal-applikazzjoni li jismacu immedjatament meta ħaġa iseħħ (ordni ġdida, bidla ta' stat) — normalment f'kombinazzjoni mal-triggers sabiex il-bidliet fid-data awtomatikament inotifikaw il-listeners, li servers tal-applikazzjoni jrieggaċu għalihom (ipinġu lil websockets, invalilaw il-caches, ittiggraw xogħol tal-background).
Huwa ta' valur għax jipprovdu imġieba event-driven real-time mingħajr l-ineffiċjenza ta' polling id-database minn kull darba lejn it-test għal bidliet (pattern komuni u vuċċ li LISTEN/NOTIFY b'eleganza tissostitwixxi).
Il-fehim tal-mekkaniżmu (LISTEN biex tissottoskriva, NOTIFY biex tippubblika, bi triggers għal notifikazzjoni awtomatika fuq bidliet fid-data) u kif l-applikazzjonijiet jużawha (jismacu għal avvenimenti biex idirizzaw reazzjonijiet real-time) huwa utli għall-bini ta' applikazzjonijiet responsivi u event-driven bl-użu ta' PostgreSQL biss.
Egwalment importanti huwa li taf il-limitazzjonijiet: notifiki mhumiex salvati (mifquda jekk ħadd m'jisma' — m'hemm l-ebda garanziji ta' durabilità), jkollhom payloads żgħar, u jinfixxi biss wara commit — għalhekk huwa adattat għall-light real-time signaling, mhux sostituzzjoni għal message broker durabbli (RabbitMQ, Kafka) meta reliability u persistence huma importanti.
Billi real-time reactivity huwa ħtieġa komuni u LISTEN/NOTIFY toffri mod built-in, poll-free biex tintlaħaq għal każi ħfief, l-fehim ta' dan — il-mekkaniżmu pub/sub, il-pattern ta' trigger, u in-partikulari l-limitazzjonijiet tiegħu (meta jkun suffiċjenti versus meta broker reali huwa meħtieġ) — huwa valur, għarfien PostgreSQL prattiċi-rilevanti għall-bini ta' applikazzjonijiet event-driven, feature built-in utli li ħafna drabi titħalla għad-dħul.