immutable、stable 和 volatile 是 postgresql 中声明函数稳定性的三个关键字：immutable 表示输入相同则输出绝对一致，允许索引和优化；stable 表示单次查询内结果一致但跨事务可能变化，适用于读取快照数据；volatile 表示每次调用都可能不同，禁止用于索引和物化视图。
SQL 函数的 IMMUTABLE、STABLE 和 VOLATILE 是 PostgreSQL 中用于声明函数行为稳定性的关键字，直接影响查询优化、索引使用、物化视图刷新和并行执行等核心机制。正确声明至关重要——声明过强（如该用 STABLE 却标 IMMUTABLE）会导致结果错误；声明过弱（如该用 IMMUTABLE 却标 VOLATILE）则让优化器放弃优化机会。
IMMUTABLE：输入相同，输出绝对一致
函数在任何情况下，只要输入参数完全相同，返回值必定相同，且不依赖任何外部状态（如表数据、配置参数、时间、随机数、事务状态等）。PostgreSQL 可对其做常量折叠、表达式预计算、函数内联，也允许在基于函数的索引中使用。
- 典型例子：
upper(text)、sqrt(float8)、md5(text)、自定义的单位换算函数（如f_celsius_to_fahrenheit(numeric)） - 禁止操作：查表、调用
now()、random()、current_user、读取pg_settings、修改任何数据 - 小技巧：若函数内部调用了其他函数，被调函数也必须全是 IMMUTABLE，否则无法声明为 IMMUTABLE
STABLE：单次执行内结果不变，跨事务可能变
函数在同一个 SQL 语句（或同一事务中的多次调用）内，对相同输入始终返回相同结果；但不同事务（或不同语句）中，结果可能变化。它不修改数据库，但可读取快照级数据（如当前事务可见的表内容）或会话级设置。
- 典型例子：
current_date、timeofday()、pg_backend_pid()、带 WHERE 条件的简单标量子查询封装函数（如get_user_name(int)查询 users 表）、依赖search_path的函数 - 允许操作：SELECT 查询（只读）、访问当前事务快照、读取配置参数（如
current_setting('app.version')） - 注意：不能在 IMMUTABLE 上下文中使用（如函数索引表达式），但可用于物化视图的 REFRESH —— 因为刷新时按事务快照执行，结果可预期
VOLATILE：每次调用都可能返回不同结果
函数每次调用都可能产生不同结果，甚至不依赖输入参数。PostgreSQL 不会对它做任何缓存或提前计算，每次都会真实执行。这是默认行为（未显式声明时即为 VOLATILE）。
- 典型例子：
random()、now()、clock_timestamp()、txid_current()、任何执行 INSERT/UPDATE/DELETE 的函数、调用dblink或外部 HTTP 请求的函数 - 关键限制：不能用于函数索引、不能在 CHECK 约束中引用（除非是 IMMUTABLE）、不能在物化视图定义中使用（因刷新无法保证一致性）
- 提醒：即使函数逻辑上“看起来稳定”，只要它调用了任意 VOLATILE 函数（比如包装了
random()），就必须声明为 VOLATILE
如何选择？三步判断法
写完函数后，依次回答三个问题：
- 它会不会修改数据库？→ 是 → 必须 VOLATILE
- 它会不会读取表、序列、事务信息或会话变量？→ 是 → 不能 IMMUTABLE；若结果仅随事务快照变化 → STABLE；若还依赖系统时钟或并发状态 → VOLATILE
- 给定相同输入，在单次查询中是否一定返回相同结果？→ 否 → VOLATILE；是 → 再看是否跨事务也恒定 → 是 → IMMUTABLE；否 → STABLE
不复杂但容易忽略：一个看似简单的字符串处理函数，若内部调用了 current_setting('app.lang')，就不再是 IMMUTABLE，而应是 STABLE；若还调用了 gen_random_uuid()，那就只能是 VOLATILE。
