★PostgreSQLカンファレンス2024 12月6日開催/チケット販売中★
他のバージョンの文書 16 | 15 | 14 | 13 | 12 | 11 | 10 | 9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

34.6. 関数の変動性分類

全ての関数は、変動性区分を持ちます。 取り得る区分は、VOLATILESTABLE、もしくはIMMUTABLEです。 CREATE FUNCTIONコマンドで分類の指定がなければデフォルトでVOLATILEになります。 変動性に関する分類は、その関数に関するオプティマイザへの約束事です。

最適化の結果を最善にするためには、関数に対して有効かつ最も厳密な変動性区分を付けなければなりません。

副作用を持つ関数は全て、VOLATILEと付けなければなりません。 こうした関数は最適化することができないためです。 関数が副作用を持たなかったとしても、単一問い合わせ内で値が変動する場合はVOLATILEと付けなければなりません。 例えば、random()currval()timeofday()などです。

計画作成を行い、すぐに実行されるような単一の対話式問い合わせを考えた場合、相対的にSTABLE区分とIMMUTABLE区分との違いはあまりありません。 このような場合、関数が計画作成中に一度実行されるか、問い合わせ実行中に一度実行されるかがあまり問題になりません。 しかし、計画が保存され、後で再利用される場合は大きな違いが現れます。 本来ならば関数が計画作成段階で早めに定数を保持することができない場合にIMMUTABLEを付けると、その後にこの計画を使用する時に古くて意味のない値が再利用されてしまうことになります。 これは、準備された文や計画をキャッシュする関数言語(PL/pgSQLなど)を使用する場合は危険です。

MVCCのスナップショット機能のため、同時実行の問い合わせによって別途変更されている可能性があるテーブルに対して選択していたとしても、SELECTコマンドのみを含む関数は、安全にSTABLEとすることができます。 PostgreSQLは、呼び出し元の問い合わせ用に確立されたスナップショットを使用してSTABLE関数を実行します。 そのため、その問い合わせの間、データベースに対して固定された視点で値を参照することになります。 また、あるトランザクションの間値が変わりませんので、current_timestamp系の関数はSTABLEとして適切であることに注意してください。

IMMUTABLE関数内のSELECTコマンドも同様のスナップショット機能を使用します。 ただし、一般的に、IMMUTABLE内でデータベースのテーブルを選択することは勧められません。 テーブルの内容が変わってしまった場合にその普遍性が壊れてしまうためです。 しかし、PostgreSQLでは、強制的に選択できないようにはしていません。

よくあるエラーは、設定パラメータに依存する結果となる関数にIMMUTABLEと付けることです。 例えば、タイムスタンプを操作する関数は、おそらくtimezoneの設定に依存した結果になります。 安全のために、こうした関数は代わりにSTABLEと付けてください。

注意: PostgreSQLリリース8.0より前のリリースでは、STABLE関数とIMMUTABLE関数がデータベースを変更できないという必要条件がシステムによって禁止されていませんでした。 リリース8.0では、この区分のSQL関数や手続き言語関数に対してSELECT以外のSQLコマンドを含めないことを必要条件とすることにより、これを禁止しています (こうした関数はまだデータベースを変更するVOLATILE関数を呼び出すことができますので、これは完全な防弾用の条件ではありません。 これを行うと、STABLEもしくはIMMUTABLE関数は呼び出した関数によってデータベースに変更が行われたことに気付かないことがわかります)。