NAME

NOTIFY - 生成一個(gè)通知

SYNOPSIS

NOTIFY name        

DESCRIPTION 描述

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

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

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

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

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

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

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

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

PARAMETERS 參數(shù)

name

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

EXAMPLES 例子

 在 psql 里配置和執(zhí)行一個(gè)監(jiān)聽(tīng)/通知對(duì)：

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

COMPATIBILITY 兼容性

 在 SQL 標(biāo)準(zhǔn)里沒(méi)有 NOTIFY 語(yǔ)句。  

SEE ALSO 參見(jiàn)

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