| PostgreSQL 8.0.0 中文文件（轉譯自 PostgreSQL 中國 製作的簡體中文版本） | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Fast Forward | Next | |
NOTIFY 命令向目前資料庫中所有執行過 LISTEN name， 正在監聽特定通知條件的前端應用發送一個通知事件。
NOTIFY 為訪問同一個 PostgreSQL 資料庫的一組進程提供了一種簡單的信號形式或進程間通訊機制。 更高級的機制（除了一個簡單的通知名以外）可以透過使用資料庫中的資料表從通知者傳遞資料到被通知者。
傳遞給前端的通知事件包括通知條件名和發出通知的後端進程PID。 資料庫設計者有責任定義用於某個資料庫的條件名和每個通知條件的含義。
通常，通知條件名與資料庫裡的資料表的名字相同， 通知時間實際上意味著"我修改了此資料庫，請看一眼有什麼新東西"。 NOTIFY 和 LISTEN 命令並不強制這種聯繫。例如，資料庫設計者可以使用幾個不同的條件名來標誌一個資料表的幾種不同改變。
當NOTIFY用於通知某一特定資料表修改的動作的發生， 一個實用的編程技巧是將 NOTIFY 放在一個由資料表更新觸發的規則裡。用這種方法， 通知將在資料表更新的時候自動觸發，而且應用程序員不會碰巧忘記處理它。
NOTIFY 和 SQL 交易用某種重要的方法進行交換。首先，如果 NOTIFY 在交易內部執行，通知事件直到交易提交才會送出。 這麼做是有道理的，因為如果交易退出了， 那麼在它裡面的所有命令都沒有效果 － 包括 NOTIFY。但如果有人希望通知事件立即發送，這就不太好了。 其次，當一個正在監聽的會話在一次交易內收到一個通知信號， 直到本次交易完成（提交或退出）之前，該通知事件將不被送到與之相連的客戶端。 同樣，如果一個通知在交易內部發送出去了， 而該交易稍後又退出了，我們就希望通知可以在某種程度上被撤消 — 但通知一旦發送出去，伺服器便不能從客戶端"收回"通知。 所以通知時間只是在交易之間傳遞。這一點就要求使用 NOTIFY 作為實時信號的應用應該確保他們的交易盡可能短。
NOTIFY 在一方面的行為象 Unix 的信號： 如果同一條件名在短時間內發出了多條信號，接收者幾次執行 NOTIFY 可能只回收到一條通知訊息。 所以依賴於收到的通知條數的方法是很不可靠的。因而，使用 NOTIFY喚醒需要關注某事的應用， 同時還要使用資料庫對像（如序列號）來跟蹤事件發生了幾次。
客戶端經常會自己發送與正在監聽的通知名一樣的 NOTIFY。 這時它（客戶端）也和其他正在監聽的會話一樣收到一個通知事件。 這樣可能導致一些無用的工作（與應用邏輯有關）－－ 例如， 對客戶端剛寫過的資料表又進行一次讀操作以發現是否有更新。 我們可以透過檢查伺服器進程的PID（在通知事件中提供） 是否與自己的後端的PID一致（從 libpq 中取得）。當他們一樣時， 說明這是其自身回彈的訊息，可以忽略。（不管前面章節是如何講的，這是一個安全的技巧。 PostgreSQL 保持自身的通知和其他到來的通知區分開。 所以您屏蔽了自己的通知後不會略過外部的通知。）