<ruby id="bdb3f"></ruby>

    <p id="bdb3f"><cite id="bdb3f"></cite></p>

      <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
        <p id="bdb3f"><cite id="bdb3f"></cite></p>

          <pre id="bdb3f"></pre>
          <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

          <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
          <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

          <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                <ruby id="bdb3f"></ruby>

                ThinkChat2.0新版上線,更智能更精彩,支持會話、畫圖、視頻、閱讀、搜索等,送10W Token,即刻開啟你的AI之旅 廣告
                # NOTIFY ## Name NOTIFY?--?生成一個通知 ## Synopsis ``` NOTIFY _channel_ [ , _payload_ ] ``` ## 描述 `NOTIFY`命令向當前數據庫中所有執行過 `LISTEN` `_channel_`, 正在監聽特定通道名字的前端應用發送一個通知事件和一個可選的"payload"字符串。 通知對所有用戶可見。 `NOTIFY`為訪問同一個PostgreSQL 數據庫的一組進程提供了一種簡單的進程間通訊機制。負載字符串可以和通知一起發送, 并且傳送結構化數據的更高級的機制可以通過使用數據庫中的表從通知者傳遞數據到接收者。 傳遞給前端的通知事件包括通知通道名、發出通知的后端進程PID 和負載字符串,如果已經指定了字符串則該負載字符串為空。 定義將要用于給定數據庫的通道名和每個意味著什么取決于數據庫設計者。 通常,通知通道名與數據庫里的表的名字相同,通知事件實際上意味著"我修改了此數據庫, 請看一眼有什么新東西"。`NOTIFY`和`LISTEN` 命令并不強制這種聯系。例如,數據庫設計者可以使用幾個不同的通道名來標志一個表的幾種不同改變。 另外,負載字符串可以用來區分各種情況。 當`NOTIFY`用于通知某一特定表修改的動作的發生, 一個實用的編程技巧是將`NOTIFY`放在一個由表更新觸發的規則里。用這種方法, 通知將在表更新的時候自動觸發,而且應用程序員不會碰巧忘記處理它。 `NOTIFY`和 SQL 事務用某種重要的方法進行交換。首先,如果`NOTIFY` 在事務內部執行,通知事件直到事務提交才會送出。這么做是有道理的,因為如果事務退出了, 那么在它里面的所有命令都沒有效果(包括`NOTIFY`)。但如果有人希望通知事件立即發送, 這就不太好了。其次,當一個正在監聽的會話在一次事務內收到一個通知信號, 直到本次事務完成(提交或退出)之前,該通知事件將不被送到與之相連的客戶端。同樣, 如果一個通知在事務內部發送出去了,而該事務稍后又退出了,就希望通知可以在某種程度上被撤消, 因為通知一旦發送出去,服務器便不能從客戶端"收回"通知,所以通知事件只是在事務之間傳遞。 這一點就要求使用`NOTIFY`作為實時信號的應用應該確保他們的事務盡可能短。 如果相同的通道名已經從相同的事務中發出了同樣的負載字符串多次, 數據庫服務器可以決定只送出一個字符串通知。另一方面,不同負載字符串的通知將總是作為不同通知傳送。 相似的,來自不同事件的通知將永遠不會被并入一個通知。除了刪除稍后復制通知的實例, `NOTIFY`保證來自相同事務的通知以它們被傳送的順序到達。 也保證來自不同事務的信息以事務提交的順序到達。 客戶端經常會自己發送與正在監聽的通知通道一樣的`NOTIFY`。 這時它(客戶端)也和其它正在監聽的會話一樣收到一個通知事件。 這樣可能導致一些無用的工作(與應用邏輯有關)。例如, 對客戶端剛寫過的表又進行一次讀操作以發現是否有更新。 可以通過檢查服務器進程的PID(在通知事件中提供)是否與自己的會話的PID 一致(從libpq中取得)避免這樣的額外工作。當他們一樣時, 說明這是其自身回彈的信息,可以忽略。 ## 參數 `_channel_` 生成信號(通知)的通知通道(任何標識符)。 `_payload_` "payload"字符串與通知交流。必須指定為簡單的字符串文本。缺省配置中必須少于8000字節。 (如果二進制數據或大量的信息需要交流,最好放在數據庫表中并發送該記錄的鍵字。) ## 注意 有一個已經發送的持有通知但目前還未被所有監聽會話處理的序列。如果這個序列滿了, 會話調用`NOTIFY`將會在提交時失敗。序列是相當大的(標準安裝中是8GB) 并且應該足夠為幾乎每個使用情況大。但是,如果會話執行`LISTEN` 并且然后進入一個事務很長時間那么將不會有清除發生。一旦序列是半滿的, 您將在日志中看到警告指向您的會話阻止清除。在這種情況下,應該確保這個會話結束他的當前事務, 這樣清理能夠進行。 一個已經執行了`NOTIFY`的事務不能準備兩階段提交。 ### pg_notify 也可以使用函數``pg_notify`(``text`, `text`) 發送一個通知。函數接受通道名作為第一個參數,負載作為第二個參數。 如果你需要使用不穩定的通道名和負載,那么使用函數比使用`NOTIFY`命令更簡單。 ## 例子 在psql里配置和執行一個監聽/通知序列: ``` LISTEN virtual; NOTIFY virtual; Asynchronous notification "virtual" received from server process with PID 8448. NOTIFY virtual, 'This is the payload'; Asynchronous notification "virtual" with payload "This is the payload" received from server process with PID 8448. LISTEN foo; SELECT pg_notify('fo' || 'o', 'pay' || 'load'); Asynchronous notification "foo" with payload "payload" received from server process with PID 14728. ``` ## 兼容性 SQL 標準里沒有`NOTIFY`語句。 ## 又見 [LISTEN](#calibre_link-983), [UNLISTEN](#calibre_link-975)
                  <ruby id="bdb3f"></ruby>

                  <p id="bdb3f"><cite id="bdb3f"></cite></p>

                    <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
                      <p id="bdb3f"><cite id="bdb3f"></cite></p>

                        <pre id="bdb3f"></pre>
                        <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

                        <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
                        <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

                        <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                              <ruby id="bdb3f"></ruby>

                              哎呀哎呀视频在线观看