Provided by: manpages-zh_1.6.3.2-1_all
NAME
NOTIFY - 生成一個通知
SYNOPSIS
NOTIFY name
DESCRIPTION 描述
NOTIFY 命令向當前數據庫中所有執行過 LISTEN name, 正在監聽特定通知條件的前端應用發送一個通 知事件。 傳遞給前端的通知事件包括通知條件名和發出通知的後端進程PID。 數據庫設計者有責任定義用於某 個數據庫的條件名和每個通知條件的含義。 通常,通知條件名與數據庫裏的表的名字相同, 通知時間實際上意味着"我修改了此數據庫,請看一 眼有什麼新東西"。 NOTIFY 和 LISTEN 命令並不強制這種聯繫。例如,數據庫設計者可以使用幾個不 同的條件名來標誌一個表的幾種不同改變。 NOTIFY 爲訪問同一個 PostgreSQL 數據庫的一組進程提供了一種簡單的信號形式或進程間通訊機制。 更高級的機制(除了一個簡單的通知名以外)可以通過使用數據庫中的表從通知者傳遞數據到被通知 者。 當NOTIFY用於通知某一特定表修改的動作的發生, 一個實用的編程技巧是將 NOTIFY 放在一個由表更 新觸發的規則裏。用這種方法, 通知將在表更新的時候自動觸發,而且應用程序員不會碰巧忘記處理 它。 NOTIFY 和 SQL 事務用某種重要的方法進行交換。首先,如果 NOTIFY 在事務內部執行,通知事件直到 事務提交纔會送出。 這麼做是有道理的,因爲如果事務退出了, 那麼在它裏面的所有命令都沒有效果 - 包括 NOTIFY。但如果有人希望通知事件立即發送,這就不太好了。 其次,當一個正在監聽的會話 在一次事務內收到一個通知信號, 直到本次事務完成(提交或退出)之前,該通知事件將不被送到與 之相連的客戶端。 同樣,如果一個通知在事務內部發送出去了, 而該事務稍後又退出了,我們就希望 通知可以在某種程度上被撤消- -但通知一旦發送出去,服務器便不能從客戶端"收回"通知。 所以通 知時間只是在事務之間傳遞。這一點就要求使用 NOTIFY 作爲實時信號的應用應該確保他們的事務儘可 能短。 NOTIFY 在一方面的行爲象 Unix 的信號: 如果同一條件名在短時間內發出了多條信號,接收者幾次執 行 NOTIFY 可能只回收到一條通知信息。 所以依賴於收到的通知條數的方法是很不可靠的。因而,使 用 NOTIFY喚醒需要關注某事的應用, 同時還要使用數據庫對象(如序列號)來跟蹤事件發生了幾次。 客戶端經常會自己發送與正在監聽的通知名一樣的 NOTIFY。 這時它(客戶端)也和其他正在監聽的 會話一樣收到一個通知事件。 這樣可能導致一些無用的工作(與應用邏輯有關)-- 例如, 對客戶 端剛寫過的表又進行一次讀操作以發現是否有更新。 我們可以通過檢查服務器進程的PID(在通知事件 中提供) 是否與自己的後端的PID一致(從 libpq 中取得)。當他們一樣時, 說明這是其自身回彈的 信息,可以忽略。(不管前面章節是如何講的,這是一個安全的技巧。 PostgreSQL 保持自身的通知和 其他到來的通知區分開。 所以你屏蔽了自己的通知後不會略過外部的通知。)
PARAMETERS 參數
name 生成信號(通知)的通知條件(任何標識符)。
EXAMPLES 例子
在 psql 裏配置和執行一個監聽/通知對: LISTEN virtual; NOTIFY virtual; Asynchronous notification "virtual" received from server process with PID 8448.
COMPATIBILITY 兼容性
在 SQL 標準裏沒有 NOTIFY 語句。
SEE ALSO 參見
LISTEN [listen(7)], UNLISTEN [unlisten(l)]
譯者
Postgresql 中文網站 何偉平 <laser@pgsqldb.org>
跋
本頁面中文版由中文 man 手冊頁計劃提供。 中文 man 手冊頁計劃:https://github.com/man-pages-zh/manpages-zh