NOTIFY name
Acknowledgement that notify command has executed.
notify コマンドが実行された証明。
Events are delivered to listening frontends; whether and how each frontend application reacts depends on its programming.
イベントが監視しているフロントエンドに配送されたことを示し ます。フロントエンドアプリケーションがイベントに対して反応 するかどうか、反応するとしたらどのように反応するのかはその プログラミングに依存します。
The NOTIFY command sends a notify event to each frontend application that has previously executed LISTEN notifyname for the specified notify condition in the current database.
NOTIFY コマンドは、現在のデータベース内で指定通 知条件に対して LISTEN notifyname を事前に実行していた各フロントエンドアプリケーションに通知イベント を送ります。
The information passed to the frontend for a notify event includes the notify condition name and the notifying backend process's PID. It is up to the database designer to define the condition names that will be used in a given database and what each one means.
通知イベントとしてフロントエンドに渡される情報には、通知条件名と通 知を行なうバックエンドプロセスの PID が含まれます。与えられたデー タベースにおいて使用される条件名とそれが何を意味するのかに関する定 義はデータベース設計者に任されています。
Commonly, the notify condition 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 condition names to signal different sorts of changes to a single table.
一般には、通知条件名はデータベースにあるどこかのテーブルの名前と同 じものであり、通知イベントは基本的には「私はこのテーブルを変更まし た。何が新しくなったかについて注目して下さい」を意味するものです。 しかし、NOTIFY と LISTEN コマ ンドでは、そのような関連付けは強制されていません。例えば、データベ ース設計者は一つのテーブルへの異なった種類の変更を知らせるために、 いくつかの異なった条件名を使用することができます。
NOTIFY provides a simple form of signal or IPC (interprocess communication) mechanism for a collection of processes accessing the same Postgres database. Higher-level mechanisms can be built by using tables in the database to pass additional data (beyond a mere condition name) from notifier to listener(s).
NOTIFY はシグナルの単純な形式、または、同一の Postgres データベースにアクセスするプロセ スを収集する IPC（プロセス内通信）機構を備えています。通知者からリ スナ（複数可）に追加的な（単なる条件名を越えた）データを渡すためのデ ータベース内のテーブルを使用することで、より高レベルの機構を構築する ことができます。
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 を特定のテーブルへの変更の発生を知らせる ために使用する場合に有用なプログラム開発テクニックは、 NOTIFY をテーブル更新時に発行されるルール内にお くことです。この方法では通知はテーブルが変更された時に自動的に行な われますので、アプリケーションプログラマが通知の実行を忘れるといっ た事故を防ぐことができます。
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 we would like all the commands within it to have had no effect, including NOTIFY. But it can be disconcerting if one is expecting the notify events to be delivered immediately. Secondly, if a listening backend receives a notify signal while it is within a transaction, the notify event will not be delivered to its connected frontend until just after the transaction is completed (either committed or aborted). Again, the reasoning is that if a notify were delivered within a transaction that was later aborted, one would want the notification to be undone somehow --- but the backend cannot "take back" a notify once it has sent it to the frontend. So notify 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 と SQL トランザクションの間にはいくつか重 要な相互作用があります。まず、NOTIFYがトランザク ション内部で実行された場合、通知イベントはトランザクションがコミット されるまで、そして、コミットされない限り配送されません。トランザクシ ョンがアボートしたならば、NOTIFY を含む、トランザ クション内で行なわれた全てのコマンドが何の影響も及ぼさないようにする という点から、このことは適切といえます。しかし、もしも通知イベントが 即座に配送されることを期待していたとすると、このことは不安になること があります。次に、監視中のバックエンドがトランザクション処理中に通知 信号を受け取った場合、通知イベントはそのトランザクションが（コミット されるかアボートされるかのどちらかによって）完了するまで、バックエン ドに接続したフロントエンドに配送されません。この理由は繰り返しになり ますが、通知がトランザクション内から配送され、その後にトランザクショ ンがアボートしたとすると、その通知も何とか取り消したくなりますが、し かし、バックエンドは一旦フロントエンドに送信した通知を「取り戻す」こ とができないということです。ですので、通知イベントはトランザクション とトランザクションの合間にのみ配送されます。この結果、実時間レベルで の信号処理のために NOTIFY を使用するアプリケーショ ンではそのトランザクション処理を短くしておかなければなりません。
NOTIFY behaves like Unix signals in one important respect: if the same condition name is signaled multiple times in quick succession, recipients may get only one notify event for several executions of NOTIFY. So it is a bad idea to depend on the number of notifies 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.
NOTIFY は次の重要な点において Unix のシグナルと 似た動作を行ないます。同一の条件名が短期間に連続して複数回発せられ た場合、複数の NOTIFY の実行に対して、受信者は 1 つの通知イベントのみしか受け取らない場合があります。ですので、通 知を受信した回数に依存することは良くない考え方となります。それより も、何かに注意をしなければならないアプリケーションを起動させる場合 に NOTIFY を使用して下さい。そして、何が起こった のかを追跡したり、何回起こったのかを数えたりする場合には、（シーケ ンスなどの）データベースオブジェクトを使って下さい。
It is common for a frontend that sends NOTIFY to be listening on the same notify name itself. In that case it will get back a notify event, just like all the other listening frontends. Depending on the application logic, this could result in useless work --- for example, re-reading a database table to find the same updates that that frontend just wrote out. In Postgres 6.4 and later, it is possible to avoid such extra work by noticing whether the notifying backend process's PID (supplied in the notify event message) is the same as one's own backend's PID (available from libpq). When they are the same, the notify 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. Postgres keeps self-notifies separate from notifies arriving from other backends, so you cannot miss an outside notify by ignoring your own notifies.)
NOTIFY を送るフロントエンドが、その同じ通知名を自 分自身が監視していることは良くあることです。この場合、他のすべての監 視を行なっているフロントエンドと全く同様に通知イベントが戻ってきます。 アプリケーションのロジックに依存しますが、これは無用な作業を行なう結 果になることがあります。例えば、フロントエンドが書き出したばかりの同 じ更新のものを検索するためのデータベースのテーブルの再読み込みです。 Postgres の 6.4 以降では、（通知イベントメ ッセージ内にある）通知を行なったバックエンドプロセスの PID と（ libpq によって入手できる）自身のバックエンドの PID が同じかどうかに注 意することで、こういった余計な作業を防止することができます。もし同じで あれば、通知イベントは自分自身から跳ね返ってきたものであり、無視するこ とができます。（前の段落で説明したことと反しますが、これは安全なテクニ ックです。Postgres は他のバックエンドからの 通知と自身からの通知を別々に保持しますので、自分自身の通知を無視したと しても外部からの通知をとり逃すことは起こり得ません。）
name can be any string valid as a name; it need not correspond to the name of any actual table. If name is enclosed in double-quotes, it need not even be a syntactically valid name, but can be any string up to 31 characters long.
nameは、名前としてど んな文字列でもかまいません。実テーブルの名前に対応させる必要は全く ありません。name がダ ブルクォートで括られていた場合は、文法的に有効なものである必要すら ありません。しかし、その長さは 31 文字までの任意の文字列という制限 があります。
In some previous releases of Postgres, name had to be enclosed in double-quotes when it did not correspond to any existing table name, even if syntactically valid as a name. That is no longer required.
以前の Postgres のリリースには、 name が文法的には有 効であっても既存のテーブル名に対応していない場合はダブルクォート で括らなければなりませんでした。これは現在は不要です。
In Postgres releases prior to 6.4, the backend PID delivered in a notify message was always the PID of the frontend's own backend. So it was not possible to distinguish one's own notifies from other clients' notifies in those earlier releases.
6.4 以前のリリースの Postgres では、 通知メッセージ内で配送されるバックエンドの PID は常にフロントエ ンド自身に対応したバックエンドの PID でした。ですので、これらの 古いリリースでは自身からの通知と他のクライアントの通知を区別する ことはできませんでした。