Provided by: manpages-zh_1.5.2-1.1_all bug

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

译者

       Postgresql 中文网站 何伟平 <laser@pgsqldb.org>