NOTIFYコマンドは、現在のデータベース内で、事前にその通知条件に対するLISTEN notifynameコマンドが実行されたクライアントアプリケーションに通知イベントを送ります。
NOTIFYは単純なシグナル送信の仕組み、さらには、同一のPostgreSQLデータベースにアクセスするプロセスの集合に対するプロセス間通信の仕組みを提供します。 データベース内のテーブルを使って通知者から（1つまたは複数の）リスナに追加的な（通知名以外の）データを渡すことにより、より高レベルの仕組みを構築することができます。
通知イベントとしてクライアントに渡される情報には、通知条件名と通知を行うサーバプロセスのPIDが含まれます。 与えられたデータベースにおいて使用される通知条件名とその意味についての定義は、データベース設計者に任されています。
通知条件名には、データベース内のテーブル名と同じものを使用するのが一般的です。通知イベントは基本的に"私はこのテーブルを変更しました。変更された箇所を確認してください"ということを意味するものです。 しかし、NOTIFYコマンドとLISTENコマンドでは、そのような関連付けは強制されていません。 例えば、データベース設計者は、1つのテーブルに対する異なる種類の変更を通知するために、複数の異なる通知条件名を使用することができます。
特定のテーブルが変更されたことを通知するためにNOTIFYを使用する場合、NOTIFYをテーブル更新時に発行されるルール内に配置すると便利です。 この場合、通知はテーブルが変更された時に自動的に行われるので、アプリケーションプログラマが通知の実行を忘れるといった事故を防ぐことができます。
NOTIFYとSQLトランザクションの間には、いくつかの重要な相互作用があります。 まず、NOTIFYがトランザクション内部で実行された場合、通知イベントはトランザクションがコミットされない限り配送されません。 トランザクションがアボートされた場合、NOTIFYだけでなく、そのトランザクション内で行われたコマンドが全て無効化されるので、これは妥当といえます。 しかし、通知イベントが即座に配送されることを期待していた場合、当惑するかもしれません。 次に、監視中のセッションがトランザクション処理中に通知信号を受け取った場合、そのトランザクションが（コミットもしくはアボートされて）完了するまで、通知イベントは接続しているクライアントに配送されません。 この理由も同じです。トランザクションに通知が配送された後にそのトランザクションがアボートされた場合、何とかして通知を取り消したくなりますが、サーバはいったんクライアントに送信した通知を"取り戻す"ことはできません。 したがって、通知イベントはトランザクションとトランザクションの合間にのみ配送されます。 この結果、実時間レベルでシグナルを処理するため、NOTIFYを使用するアプリケーションではトランザクション処理を短くしておかなければなりません。
NOTIFYは、次の重要な点においてUnixのシグナルと似た動作を行います。 同一の通知条件名が短期間に連続して複数回送られた場合、NOTIFYが複数回実行されても、受信者が通知イベントを1つしか受け取らないことがあります。 したがって、通知を受信した回数に依存した処理を行うのはお勧めできません。 それよりも、何かに注意をしなければならないアプリケーションを起動する時にNOTIFYを使用して、 何が起こったのかを追跡したり、何回起こったのかを数えたりする場合には、（シーケンスなどの）データベースオブジェクトを使ってください。
NOTIFYを実行するクライアント自身が、その通知の通知名を監視していることはよくあります。 この場合、同じ通知名を監視する他のセッションに対するのと同じように通知イベントが戻ってきます。 アプリケーションのロジックにもよりますが、これは無駄な作業になることがあります。 例えば、そのセッションが書き出したばかりのデータベースに対する更新を調べるためにテーブルの再読み込みを行う場合などが考えられます。 通知イベントメッセージ内にある通知元セッションのサーバプロセスのPIDと、libpqで得られる自分自身のPIDが同じかどうかに注意することで、こういった余計な作業を回避できます。 PIDが同じであれば、その通知イベントは自分自身から跳ね返ってきたものであり、無視することができます（前の段落の内容と反しますが、これは安全なテクニックです。 PostgreSQLは他のセッションからの通知と自分自身からの通知を別々に保持するので、自分自身からの通知を無視しても外部からの通知を取り逃すことはあり得ません）。