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)]

  #p#

NAME

NOTIFY - generate a notification

SYNOPSIS

NOTIFY name        

DESCRIPTION

The NOTIFY command sends a notification event to each client application that has previously executed LISTEN name for the specified notification name in the current database.

The information passed to the client for a notification event includes the notification name and the notifying session's server process PID. It is up to the database designer to define the notification names that will be used in a given database and what each one means.

Commonly, the notification name is the same as the name of some table in the database, and the notify event essentially means, ``I changed this table, take a look at it to see what's new''. But no such association is enforced by the NOTIFY and LISTEN commands. For example, a database designer could use several different notification names to signal different sorts of changes to a single table.

NOTIFY provides a simple form of signal or interprocess communication mechanism for a collection of processes accessing the same PostgreSQL database. Higher-level mechanisms can be built by using tables in the database to pass additional data (beyond a mere notification name) from notifier to listener(s).

When NOTIFY is used to signal the occurrence of changes to a particular table, a useful programming technique is to put the NOTIFY in a rule that is triggered by table updates. In this way, notification happens automatically when the table is changed, and the application programmer can't accidentally forget to do it.

NOTIFY interacts with SQL transactions in some important ways. Firstly, if a NOTIFY is executed inside a transaction, the notify events are not delivered until and unless the transaction is committed. This is appropriate, since if the transaction is aborted, all the commands within it have had no effect, including NOTIFY. But it can be disconcerting if one is expecting the notification events to be delivered immediately. Secondly, if a listening session receives a notification signal while it is within a transaction, the notification event will not be delivered to its connected client until just after the transaction is completed (either committed or aborted). Again, the reasoning is that if a notification were delivered within a transaction that was later aborted, one would want the notification to be undone somehow---but the server cannot ``take back'' a notification once it has sent it to the client. So notification events are only delivered between transactions. The upshot of this is that applications using NOTIFY for real-time signaling should try to keep their transactions short.

NOTIFY behaves like Unix signals in one important respect: if the same notification name is signaled multiple times in quick succession, recipients may get only one notification event for several executions of NOTIFY. So it is a bad idea to depend on the number of notifications received. Instead, use NOTIFY to wake up applications that need to pay attention to something, and use a database object (such as a sequence) to keep track of what happened or how many times it happened.

It is common for a client that executes NOTIFY to be listening on the same notification name itself. In that case it will get back a notification event, just like all the other listening sessions. Depending on the application logic, this could result in useless work, for example, reading a database table to find the same updates that that session just wrote out. It is possible to avoid such extra work by noticing whether the notifying session's server process PID (supplied in the notification event message) is the same as one's own session's PID (available from libpq). When they are the same, the notification event is one's own work bouncing back, and can be ignored. (Despite what was said in the preceding paragraph, this is a safe technique. PostgreSQL keeps self-notifications separate from notifications arriving from other sessions, so you cannot miss an outside notification by ignoring your own notifications.)  

PARAMETERS

name

Name of the notification to be signaled (any identifier).

EXAMPLES

Configure and execute a listen/notify sequence from psql:

LISTEN virtual;
NOTIFY virtual;
Asynchronous notification "virtual" received from server process with PID 8448.

COMPATIBILITY

There is no NOTIFY statement in the SQL standard.  

SEE ALSO

LISTEN [listen(7)], UNLISTEN [unlisten(l)]