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