# 35.6\. 函數易失性范疇 每個函數都有一個_易失性_級別`VOLATILE`，`STABLE`或者 `IMMUTABLE`。 如果[CREATE FUNCTION](#calibre_link-4)命令沒有明確聲明范疇的話， `VOLATILE`就是缺省。易失性范疇是給優化器的一個關于函數行為的承諾： * `VOLATILE`可以做任何事情，包括修改數據庫。 它可以在使用同樣參數調用時返回不同的結果。優化器對這樣的函數不做任何假設。 一個使用易失函數的查詢在需要數據值的時候每次都重新計算函數的值。 * `STABLE`函數不會修改數據庫， 并且保證在同一個查詢的環境里給出相同參數的情況下，會給出相同的結果。 這個范疇允許優化器在一個查詢里把多個函數調用優化成一個。 特別是在索引掃描的條件表達式里面包含這樣的函數是安全的。 因為索引掃描只計算一次比較值，而不是每行一次。 在索引掃描條件里使用一個`VOLATILE`函數是非法的。 * `IMMUTABLE`函數不會修改數據庫， 并且保證在任何情況下同樣的參數永遠返回同樣的結果。 這個范疇允許優化器在查詢調用函數的時候預先把函數計算成一個常量參數。 比如，類似`SELECT ... WHERE x = 2 + 2`的查詢可以簡化成 `SELECT ... WHERE x = 4`，因為在加法操作符下層的函數是標記為 `IMMUTABLE`的。 為了最佳的優化結果，應該盡可能使用最嚴格的易失性范疇標記你的函數。 任何有副作用的函數都_必須_標記為`VOLATILE`， 這樣對它的調用就不會被優化。即使一個函數沒有副作用， 但它的數值可能在一個查詢里改變，那么也必須標記為`VOLATILE`； 例如`random()`，`currval()`，`timeofday()`函數。 另一個重要例子是`current_timestamp`函數簇描述為`STABLE`， 因為他們的值在一個事務中沒有改變。 在那些簡單的規劃后馬上執行的交互查詢上，`STABLE`和 `IMMUTABLE`沒有什么區別： 函數是在規劃開始時執行還是在查詢開始時執行的差別并不大。 但是如果規劃被保存并且后來被重用，那差別可就大了。 如果把一個函數標記為`IMMUTABLE`而它實際上又不是， 那么就會導致在隨后使用其規劃的時候用上一個不完整的數值。 如果在使用預先準備好語句或者使用一種緩沖規劃的函數語言(比如PL/pgSQL)， 那么后果可能很嚴重。 為了編寫SQL或在任何標準的程序語言的函數，還有一個通過波動性范疇決定的重要屬性， 即由SQL命令決定的任何數據變化能見度正在調用函數。 一個`VOLATILE`函數將看到這樣的變化，`STABLE` 或者`IMMUTABLE`函數不這樣。這種行為 使用MVCC快照行為實現（參閱[Chapter 13](#calibre_link-444)）： `STABLE`和`IMMUTABLE`函數使用快照 確立為調用查詢的開始， 而`VOLATILE`函數每個查詢執行開始時獲得一個新的快照。 > **Note:** 用C寫的函數管理快照然而是他們想要的，但是使C函數這樣進行工作往往是一個好主意。 因為快照行為， 一個只包含`SELECT`命令的函數可以安全地標記為`STABLE`， 即使它所選擇的表可能會被其它并發查詢修改也一樣。 PostgreSQL將會在執行`STABLE` 函數時為調用它的查詢建立快照， 因此它在該查詢的生存期內都會看到一致的數據庫視圖。 同樣的快照行為也用于`IMMUTABLE`函數里面的`SELECT`命令。 通常，在一個`IMMUTABLE`函數里選擇一個數據庫的表是不明智的， 因為如果表的內容改變，那么這種不變性就將改變。不過， PostgreSQL并不禁止你這樣做。 一個常見的錯誤是把一個函數標記為`IMMUTABLE`， 而實際上這個函數的結果依賴某個配置參數。比如， 一個操作時間戳的函數可能有依賴于[TimeZone](#calibre_link-793)設置的結果。 為了安全考慮，這樣的函數應該標記為`STABLE`。 > **Note:** 在PostgreSQL之前，要求`STABLE`和 `IMMUTABLE` 函數不能修改數據庫這個約束并未由系統強制。版本8.0 通過要求這類函數不能包含`SELECT`之外的 SQL 命令來強制這個約束。 不過，這么做并不是完全防彈的升級， 因為這樣的函數仍然可以調用那些可能修改數據庫的`VOLATILE`函數。 如果你這么做的話將會發現`STABLE`或者 `IMMUTABLE` 并不會覺察到被它調用的函數對數據庫所做的修改。