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>