<!--
$Header: /usr/prj/pg/cvsroot/doc/doc/src/sgml/ref/notify.sgml,v 1.6 2001/09/13 05:03:38 k-kondo Exp $
Postgres documentation
-->

<refentry id="SQL-NOTIFY">
 <refmeta>
  <refentrytitle id="sql-notify-title">
   NOTIFY
  </refentrytitle>
  <refmiscinfo>SQL<!-- Language Statements -->言語</refmiscinfo>
 </refmeta>
 <refnamediv>
  <refname>
   NOTIFY
  </refname>
  <refpurpose>
   <!--
   Signals all frontends and backends listening on a notify condition -->
   ある通知条件を監視するすべてのフロントエンド、バックエンドに信号を送信します。<indexterm><primary>NOTIFY</primary></indexterm><indexterm><primary>SQL</primary><secondary>NOTIFY</secondary></indexterm><indexterm><primary sortas="つうちじょうけん">通知条件</primary><secondary sortas="そうしん">送信</secondary></indexterm>

  </refpurpose>
 </refnamediv>
 <refsynopsisdiv>
  <refsynopsisdivinfo>
   <date>1999-07-20</date>
  </refsynopsisdivinfo>
<synopsis>
NOTIFY <replaceable class="PARAMETER">name</replaceable>
</synopsis>

  <refsect2 id="R2-SQL-NOTIFY-1">
   <refsect2info>
    <date>1998-10-07</date>
   </refsect2info>
   <title>
    <!-- Inputs -->入力
   </title>

    <variablelist>
     <varlistentry>
      <term><replaceable class="PARAMETER">notifyname</replaceable></term>
      <listitem>
       <para>
	<!-- Notify condition to be signaled. -->
        信号が送られる通知条件です。

       </para>
      </listitem>
     </varlistentry>
    </variablelist>
  </refsect2>

  <refsect2 id="R2-SQL-NOTIFY-2">
   <refsect2info>
    <date>1998-10-07</date>
   </refsect2info>
   <title>
    <!-- Outputs -->出力
   </title>

    <variablelist>
     <varlistentry>
      <term><computeroutput>
NOTIFY
       </computeroutput></term>
      <listitem>
       <para>
	<!-- Acknowledgement that notify command has executed. -->
        notifyコマンドが実行された場合に返されます。

       </para>
      </listitem>
     </varlistentry>
     <varlistentry>
      <term><replaceable>Notify events</replaceable></term>
      <listitem>
       <para>
        <!--
	Events are delivered to listening frontends; whether and how
        each frontend application reacts depends on its programming. -->

        イベントが監視しているフロントエンドに配送された場合に返されます。フロントエンドアプリケーションがイベントに対して反応するかどうか、反応するとしたらどのように反応するのかはそのプログラミングに依存します。

       </para>
      </listitem>
     </varlistentry>
    </variablelist>
  </refsect2>
 </refsynopsisdiv>

 <refsect1 id="R1-SQL-NOTIFY-1">
  <refsect1info>
   <date>1998-10-07</date>
  </refsect1info>
  <title>
   <!-- Description -->説明
  </title>
  <para>
   <!--
   The <command>NOTIFY</command> command sends a notify event to each
   frontend application that has previously executed
   <command>LISTEN <replaceable class="parameter">notifyname</replaceable>
   </command>
   for the specified notify condition in the current database. -->

   <command>NOTIFY</command>コマンドは、現在のデータベース内で指定された通知条件に対して<command>LISTEN <replaceable class="parameter">notifyname</replaceable></command>を事前に実行していた各フロントエンドアプリケーションに通知イベントを送ります。

  </para>
  <para>
   <!--
   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が含まれます。与えられたデータベースにおいて使用される条件名とそれが何を意味するのかに関する定義はデータベース設計者に任されています。

  </para>
  <para>
   <!--
   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 <command>NOTIFY</command>
   and <command>LISTEN</command> commands.  For example, a database
   designer could use several different condition names
   to signal different sorts of changes to a single table. -->

   一般には、通知条件名はデータベースにあるどこかのテーブルの名前と同じもので、通知イベントは本質的に「私はこのテーブルを変更ました。何が新しくなったかについて注目してください」ということを意味するものです。しかし、<command>NOTIFY</command>コマンドと<command>LISTEN</command>コマンドでは、そのような関連付けは強制されていません。たとえば、データベース設計者は1つのテーブルへの異なった種類の変更を知らせるために、いくつかの異なった条件名を使用することができます。

  </para>
  <para>
   <!--
   <command>NOTIFY</command> provides a simple form of signal or
   IPC (interprocess communication) mechanism for a collection of processes
   accessing the same <productname>Postgres</productname> 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). -->

   <command>NOTIFY</command>はシグナルの単純な形式、または、同一の<productname>Postgres</productname>データベースにアクセスするプロセスを収集するIPC（プロセス間通信）機構を備えています。通知者からリスナ（複数可）に追加的な（単なる条件名を越えた）データを渡すためのデータベース内のテーブルを使用することで、より高レベルの機構を構築することができます。

  </para>
  <para>
   <!--
   When <command>NOTIFY</command> is used to signal the occurrence
   of changes to a particular table, a useful programming technique
   is to put the <command>NOTIFY</command> 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. -->

   <command>NOTIFY</command>を特定のテーブルへの変更の発生を知らせるために使用する場合に有用なプログラム開発テクニックは、<command>NOTIFY</command>をテーブル更新時に発行されるルール内におくことです。この方法では通知はテーブルが変更されたときに自動的に行われますので、アプリケーションプログラマが通知の実行を忘れるような事故を防ぐことができます。

  </para>
  <para>
   <!--<command>NOTIFY</command> interacts with SQL transactions in some
   important ways.  Firstly, if a <command>NOTIFY</command> 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 <command>NOTIFY</command>.  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 
   <command>NOTIFY</command> for real-time signaling should 
   try to keep their transactions short. -->

   <command>NOTIFY</command>とSQLトランザクションの間にはいくつかの重要な相互作用があります。まず、<command>NOTIFY</command>がトランザクション内部で実行された場合、通知イベントはトランザクションがコミットされるまで、そして、コミットされない限り配送されません。トランザクションを中止したならば、<command>NOTIFY</command>を含む、トランザクション内で行われたすべてのコマンドが何の影響も及ぼさないようにするという点から、このことは適切といえます。しかし、もしユーザーが、通知イベントが即座に配送されることを期待していたとすると、このことは不安定要素になることがあります。次に、監視中のバックエンドがトランザクション処理中に通知信号を受け取った場合、通知イベントはそのトランザクションが（コミットされるか中止されるかのどちらかによって）完了するまで、バックエンドに接続したフロントエンドに配送されません。この理由は繰り返しになりますが、通知がトランザクション内から配送され、その後にトランザクションが中止されたとすると、その通知も何とか取り消したくなりますが、しかし、バックエンドはいったんフロントエンドに送信した通知を「取り戻す」ことができないということです。ですから、通知イベントはトランザクションとトランザクションの合間にのみ配送されます。この結果、実時間レベルでの信号処理のために<command>NOTIFY</command>を使用するアプリケーションではそのトランザクション処理を短くしておかなければいけません。
   

  </para>
  <para>
   <!-- 
   <command>NOTIFY</command> 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 <command>NOTIFY</command>.  So it is a bad idea to depend on the number
   of notifies received.  Instead, use <command>NOTIFY</command> 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. -->

   <command>NOTIFY</command>は、次の重要な点においてUnixのシグナルと似た動作を行います。同一の条件名が短期間に連続して複数回発せられた場合、複数の<command>NOTIFY</command>の実行に対して、受信者は1つの通知イベントのみしか受け取らない場合があります。ですので、通知を受信した回数に依存することはよくない考え方となります。それよりも、何かに注意をしなければならないアプリケーションを起動させる場合に<command>NOTIFY</command>を使用してください。そして、何が起こったのかを追跡したり、何回起こったのかを数えたりする場合には、データベースオブジェクト（シーケンス）を使ってください。

  </para>
  <para>
   <!-- 
   It is common for a frontend that sends <command>NOTIFY</command> 
   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 <productname>Postgres</productname> 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.
   <productname>Postgres</productname> keeps self-notifies separate 
   from notifies arriving from other backends, so you cannot miss 
   an outside notify by ignoring your own notifies.) -->

   <command>NOTIFY</command>を送るフロントエンドが、その同じ通知名を自分自身が監視していることはよくあることです。この場合、他のすべての監視を行っているフロントエンドとまったく同様に通知イベントが戻ってきます。アプリケーションのロジックに依存しますが、これは無駄な作業を行う結果になることがあります。たとえば、そのフロントエンドが書き出したばかりのデータベースに何か更新があったかどうかを調べるためにテーブルの再読み込みを行うことです。<productname>Postgres</productname> 6.4以降では、（通知イベントメッセージ内にある）通知を行ったバックエンドプロセスのPIDと（libpqによって入手できる）自身のバックエンドのPIDが同じかどうかに注意することで、こういった余計な作業を防止することができます。もし同じであれば、通知イベントは自分自身から跳ね返ってきたものであり、無視することができます（前の段落で説明したことと反しますが、これは安全なテクニックです。<productname>Postgres</productname>は他のバックエンドからの通知と自身からの通知を別々に保持しておきますので、自分自身の通知を無視したとしても外部からの通知をとり逃すことは起こり得ません）。

  </para>

  <refsect2 id="R2-SQL-NOTIFY-3">
   <refsect2info>
    <date>1998-10-07</date>
   </refsect2info>
   <title>
    <!-- Notes -->注釈
   </title>
   <para>
    <!-- <replaceable class="PARAMETER">name</replaceable>
    can be any string valid as a name;
    it need not correspond to the name of any actual table.  If
    <replaceable class="PARAMETER">name</replaceable>
    is enclosed in double-quotes, it need not even be a syntactically
    valid name, but can be any string up to 31 characters long.
    -->

    <replaceable class="PARAMETER">name</replaceable>は、名前としてどんな文字列でもかまいません。実テーブルの名前に対応させる必要はまったくありません。<replaceable class="PARAMETER">name</replaceable>が二重引用符で囲まれていた場合は、文法的に有効なものである必要すらありません。しかし、長さは31文字までの任意の文字列という制限があります。

   </para>
   <para>
    <!-- In some previous releases of
    <productname>Postgres</productname>,
    <replaceable class="PARAMETER">name</replaceable>
    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. -->

    以前の<productname>Postgres</productname>のリリースには、<replaceable class="PARAMETER">name</replaceable>が文法的には有効であっても既存のテーブル名に対応していない場合は二重引用符で囲まなければいけませんでした。これは現在は不要です。

   </para>
   <para>
    <!-- 
    In <productname>Postgres</productname> 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以前のリリースの<productname>Postgres</productname>では、通知メッセージ内で配送されるバックエンドのPIDは常にフロントエンド自身に対応したバックエンドのPIDでした。ですから、これらの古いリリースでは自身からの通知と他のクライアントの通知を区別することはできませんでした。

   </para>
  </refsect2>
 </refsect1>

 <refsect1 id="R1-SQL-NOTIFY-2">
  <title>
   <!-- Usage -->使用方法
  </title>
  <para>
   <!-- Configure and execute a listen/notify sequence from
   <application>psql</application>: -->

   <application>psql</application>から監視/通知処理の設定と実行を行うには以下のようにします。
</para>

<programlisting>
LISTEN virtual;
NOTIFY virtual;
Asynchronous NOTIFY 'virtual' from backend with pid '8448' received. 
</programlisting>
 </refsect1>

 <refsect1 id="R1-SQL-NOTIFY-3">
  <title>
   <!-- Compatibility -->互換性
  </title>

  <refsect2 id="R2-SQL-NOTIFY-4">
   <refsect2info>
    <date>1998-09-24</date>
   </refsect2info>
   <title>
    SQL92
   </title>
   <para>
    <!-- There is no <command>NOTIFY</command> statement in
    <acronym>SQL92</acronym>. -->

    <acronym>SQL92</acronym>には<command>NOTIFY</command>
    はありません。 

   </para>
  </refsect2>
 </refsect1>
</refentry>

<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-omittag:nil
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
sgml-parent-document:nil
sgml-default-dtd-file:"../reference.ced"
sgml-exposed-tags:nil
sgml-local-catalogs:"/usr/lib/sgml/catalog"
sgml-local-ecat-files:nil
End:
-->
