LISTEN आणि NOTIFY PostgreSQL मध्ये एक बिल्ट-इन publish/subscribe मेसेजिंग सिस्टम प्रदान करतात — एक सेशन चॅनेलवर सूचना पाठवू शकते, आणि त्या चॅनेलवर ऐकणारे इतर सेशन ते तत्काळ प्राप्त करतात. पोलिंग न करता डेटाबेसमधून रिअल-टाइम इव्हेंट्स पुश करण्याचा हा एक हलका मार्ग आहे.
LISTEN order_created;
NOTIFY order_created, ;
LISTEN चॅनेलसाठी सबस्क्राइब करते; NOTIFY यावर प्रकाशित करते (ऐच्छिक मजकूर पेलोडसह). श्रोताओं को अतुल्यकालिक सूचनाएं मिलती हैं — कोई पोलिंग की आवश्यकता नहीं.
-- 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
NOTIFY एक ट्रिगर सह एकत्र करणे डेटाबेसला स्वयंचलितपणे इव्हेंट्स पुश करण्यास सक्षम करते जेव्हा डेटा बदलतो (नया ऑर्डर, स्थिती अद्यतन) — चॅनेलवर ऐकणारे अनुप्रयोग सर्व्हर रिअल टाइममध्ये प्रतिक्रिया देतात.
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 PostgreSQL चा एक उपयुक्त, काहीसा कमज्ञात वैशिष्ट्य आहे जो बिल्ट-इन पब/सब मेसेजिंग प्रदान करते, पोलिंग न करता अनुप्रयोगांमध्ये रिअल-टाइम प्रतिक्रियाशीलता जोडण्यासाठी मूल्यवान आहे.
मूल मूल्य म्हणजे डेटाबेसला इव्हेंट्स पुश करण्यास सक्षम करणे ऐकणार्या अनुप्रयोग सेशनमध्ये तत्काळ जेव्हा काहीतरी घडते (नया ऑर्डर, स्थिती बदल) — साधारणतः ट्रिगर्स सह एकत्र केले जाते जेणेकरून डेटा बदल स्वयंचलितपणे श्रोताओं को सूचित करते, ज्या अनुप्रयोग सर्व्हर प्रतिक्रिया देतात (वेबसॉकेट्समध्ये पुश करणे, कॅशेस अमान्य करणे, पार्श्वभूमी कार्य ट्रिगर करणे).
हे मूल्यवान आहे कारण हे पोलिंग करण्याच्या अक्षमतेशिवाय रिअल-टाइम इव्हेंट-चालित वर्तन प्रदान करते डेटाबेस बार-बार जाचण्यासाठी बदलांच्या तपासणीसाठी (एक सामान्य, अपव्यय पॅटर्न ज्या LISTEN/NOTIFY सुंदरपणे बदलते).
यंत्रणा समजणे (सबस्क्राइब करण्यासाठी LISTEN, प्रकाशित करण्यासाठी NOTIFY, डेटा बदलांवर स्वयंचलित सूचनेसाठी ट्रिगर्स) आणि अनुप्रयोग हे कसे वापरतात (इव्हेंट्स ऐकणे रिअल-टाइम प्रतिक्रिया चालित करण्यासाठी) केवळ PostgreSQL वापरून प्रतिक्रियाशील, इव्हेंट-चालित अनुप्रयोग तयार करण्यासाठी उपयुक्त आहे.
तितकेच महत्वाचे म्हणजे मर्यादा जाणून घेणे: सूचना कायम केल्या जात नाहीत (कोणी ऐकत नसल्यास गमावल्या जातात — कोणतीही स्थायित्व हमी नाहीत), लहान पेलोड्स आहेत, आणि केवळ कमिट नंतर फायर करतात — त्यामुळे हे हलके रिअल-टाइम सिग्नलिंगसाठी उपयुक्त आहे, एक टिकाऊ संदेश ब्रोकर (RabbitMQ, Kafka) ची जागा नाही जेव्हा विश्वसनीयता आणि स्थायित्व महत्वाचे आहे.
रिअल-टाइम प्रतिक्रियाशीलता एक सामान्य आवश्यकता आहे आणि LISTEN/NOTIFY हलके केसांसाठी बिल्ट-इन, पोलिंग-रहित मार्ग देते, यंत्रणा समजणे — पब/सब यंत्रणा, ट्रिगर पॅटर्न, आणि महत्वाचे म्हणजे त्याच्या मर्यादा (कधी हे पुरेसे आहे विरुद्ध कधी एक वास्तविक ब्रोकर आवश्यक आहे) — इव्हेंट-चालित अनुप्रयोग तयार करण्यासाठी मूल्यवान, व्यावहारिकरित्या-संबंधित PostgreSQL ज्ञान आहे, एक उपयुक्त बिल्ट-इन वैशिष्ट्य जे अनेकदा अनदेखित केले जाते.