Provided by:
manpages-zh_1.5-1_all 
NAME
NOTIFY - 生成一茬q知
SYNOPSIS
NOTIFY name
DESCRIPTIONyz
NOTIFY 命令向當前數據庫中所有執行過 LISTEN name，
正在監聽特定通知條件的前端應用發送一茬q知事件。
傳遞給前端的通知事件包括通知條件名和發出通知的後端進程PID。 數據庫設-
p者有責任定義用於某蚍畬w的條件名和每茬q知條件的含義。
通常，通知條件名與數據庫裏的表的名字相同， 通知時間實際上意味著"我-
蚹鴾F此數據庫，請看一眼有什麼新東西"。 NOTIFY 和 LISTEN
命令並不強制這種聯系。例如，數據庫設p者可以使用幾茪ㄕP的條件名來標誌一-
茠磲煽X種不同改變。
NOTIFY 為訪問同一 PostgreSQL
數據庫的一組進程提供了一種簡單的信號形式或進程間通訊機制。
更高級的機制（除了一-
蚋眾瑼熙q知名以外）可以通過使用數據庫中的表從通知者傳遞數據到被通知者。
當NOTIFY用於通知某一特定表蚹麊滌囮@的發生， 一蚢磪峈瑤s程技巧是將
NOTIFY 放在一茈悛礂騝s觸發的規則裏。用這種方法， 通知將在表更新的時-
啈菾岉眶o，而且應用程式不會碰巧忘記處理它。
NOTIFY 和 SQL 事務用某種南的方法進行交換。漸，如果 NOTIFY
在事務內部執行，通知事件直到事務提交才會送出。
這麼做是有道理的，因為如果事務退出了， 那麼在它裏悸漫狾釧R令都沒有效果
－ 包括 NOTIFY。但如果有人希望通知事件立即發送，這就不太好了。
其次，當一茈縝b監聽的會話在一次事務內收到一茬q知信號，
直到本次事務完成（提交或退出）之前，該通知事件將不被送到與之相連的客戶端。
同樣，如果一茬q知在事務內部發送出去了， 而該事務稍後又退出了，我-
抴N希望通知可以在某種程度上被撤消－
－但通知一旦發送出去，伺服器便不能從客戶端"收回"通知。
所以通知時間只是在事務之間傳遞。這一點就n求使用 NOTIFY
作為實時信號的應用應該確保他怐漕犮i能短。
NOTIFY 在一方悸漲甈偎 Unix 的信號：
如果同一條件名在短時間內發出了多條信號，接收者幾次執行 NOTIFY
可能只回收到一條通知信息。
所以依賴於收到的通知條數的方法是很不可靠的。因而，使用 NOTIFY喚醒需-
n關注某事的應用， 同時還-
n使用數據庫對象（如序列號）來跟蹤事件發生了幾次。
客戶端經常會自己發送與正在監聽的通知名一樣的 NOTIFY。
這時它（客戶端）也和其他正在監聽的會話一樣收到一茬q知事件。 這樣可能導-
P一些無用的工作（與應用邏輯有關）－－ 例如， 對客戶端-
頛g過的表又進行一次讀操作以發現是否有更新。 我-
怚i以通過檢查伺服器進程的PID（在通知事件中提供）
是否與自己的後端的PID一P（從 libpq 中取得）。當他怳@樣時，
說明這是其自谷^彈的信息，可以忽略。（不管前掖兢`是如何講的，這是一-
茼w全的技巧。 PostgreSQL 保持自赤熙q知和其他到來的通知區分開。
所以你屏蔽了自己的通知後不會略過外部的通知。）
PARAMETERS數
name 生成信號（通知）的通知條件（任何標識符）。
EXAMPLESl
在 psql 裏配置和執行一蚨岒/通知對：
LISTEN virtual;
NOTIFY virtual;
Asynchronous notification "virtual" received from server process with PID 8448.
COMPATIBILITYe性
在 SQL 標準裏沒有 NOTIFY 語句。
SEE ALSO見
LISTEN [listen(7)], UNLISTEN [unlisten(l)]
者
Postgresql <laser@pgsqldb.org>