NAME

NOTIFY - 生成一個通知

SYNOPSIS

NOTIFY name        

DESCRIPTION 描述

NOTIFY 命令向當(dāng)前數(shù)據(jù)庫中所有執(zhí)行過 LISTEN name， 正在監(jiān)聽特定通知條件的前端應(yīng)用發(fā)送一個通知事件。

 傳遞給前端的通知事件包括通知條件名和發(fā)出通知的后端進(jìn)程PID。 數(shù)據(jù)庫設(shè)計者有責(zé)任定義用于某個數(shù)據(jù)庫的條件名和每個通知條件的含義。

 通常，通知條件名與數(shù)據(jù)庫里的表的名字相同， 通知時間實際上意味著"我修改了此數(shù)據(jù)庫，請看一眼有什么新東西"。 NOTIFY 和 LISTEN  命令并不強制這種聯(lián)系。例如，數(shù)據(jù)庫設(shè)計者可以使用幾個不同的條件名來標(biāo)志一個表的幾種不同改變。

NOTIFY 為訪問同一個 PostgreSQL 數(shù)據(jù)庫的一組進(jìn)程提供了一種簡單的信號形式或進(jìn)程間通訊機(jī)制。 更高級的機(jī)制（除了一個簡單的通知名以外）可以通過使用數(shù)據(jù)庫中的表從通知者傳遞數(shù)據(jù)到被通知者。

 當(dāng)NOTIFY用于通知某一特定表修改的動作的發(fā)生， 一個實用的編程技巧是將 NOTIFY 放在一個由表更新觸發(fā)的規(guī)則里。用這種方法， 通知將在表更新的時候自動觸發(fā)，而且應(yīng)用程序員不會碰巧忘記處理它。

NOTIFY 和 SQL 事務(wù)用某種重要的方法進(jìn)行交換。首先，如果 NOTIFY 在事務(wù)內(nèi)部執(zhí)行，通知事件直到事務(wù)提交才會送出。 這么做是有道理的，因為如果事務(wù)退出了， 那么在它里面的所有命令都沒有效果 － 包括 NOTIFY。但如果有人希望通知事件立即發(fā)送，這就不太好了。 其次，當(dāng)一個正在監(jiān)聽的會話在一次事務(wù)內(nèi)收到一個通知信號， 直到本次事務(wù)完成（提交或退出）之前，該通知事件將不被送到與之相連的客戶端。 同樣，如果一個通知在事務(wù)內(nèi)部發(fā)送出去了， 而該事務(wù)稍后又退出了，我們就希望通知可以在某種程度上被撤消－ －但通知一旦發(fā)送出去，服務(wù)器便不能從客戶端"收回"通知。 所以通知時間只是在事務(wù)之間傳遞。這一點就要求使用 NOTIFY 作為實時信號的應(yīng)用應(yīng)該確保他們的事務(wù)盡可能短。

NOTIFY 在一方面的行為象 Unix 的信號： 如果同一條件名在短時間內(nèi)發(fā)出了多條信號，接收者幾次執(zhí)行 NOTIFY 可能只回收到一條通知信息。 所以依賴于收到的通知條數(shù)的方法是很不可靠的。因而，使用 NOTIFY喚醒需要關(guān)注某事的應(yīng)用， 同時還要使用數(shù)據(jù)庫對象（如序列號）來跟蹤事件發(fā)生了幾次。

 客戶端經(jīng)常會自己發(fā)送與正在監(jiān)聽的通知名一樣的 NOTIFY。 這時它（客戶端）也和其他正在監(jiān)聽的會話一樣收到一個通知事件。 這樣可能導(dǎo)致一些無用的工作（與應(yīng)用邏輯有關(guān)）－－ 例如， 對客戶端剛寫過的表又進(jìn)行一次讀操作以發(fā)現(xiàn)是否有更新。 我們可以通過檢查服務(wù)器進(jìn)程的PID（在通知事件中提供） 是否與自己的后端的PID一致（從 libpq 中取得）。當(dāng)他們一樣時， 說明這是其自身回彈的信息，可以忽略。（不管前面章節(jié)是如何講的，這是一個安全的技巧。 PostgreSQL 保持自身的通知和其他到來的通知區(qū)分開。 所以你屏蔽了自己的通知后不會略過外部的通知。）  

PARAMETERS 參數(shù)

name

 生成信號（通知）的通知條件（任何標(biāo)識符）。

EXAMPLES 例子

 在 psql 里配置和執(zhí)行一個監(jiān)聽/通知對：

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

COMPATIBILITY 兼容性

 在 SQL 標(biāo)準(zhǔn)里沒有 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)]