PostgreSQL 生成列使用 to_char，报 generation expression is not immutable

日期字段已经是 date，想增加一个自动生成的展示字段，定义里使用 to_char(evtdate, 'YYYY-Mon-DD')，建列却报：

ERROR: generation expression is not immutable

先区分两件事：日期值是否会变，以及这个表达式是否被数据库认定为不可变。生成列要求表达式中的函数满足后者。把字段从 timestamp 改为 date，或给格式串换一种写法，不会自动改变所调用函数的分类。

以下按 PostgreSQL 18 的规则说明，讨论存储型生成列 STORED 和日期转展示文本。其他表达式也会触发同一错误，应检查它们自己的函数、运算符和隐式类型转换，不能都归因于 to_char。

查看完整表达式和函数分类

先保留失败的建列语句，确认源列类型。在 psql 中查看表定义，也检查迁移工具实际发送的 SQL。示例中的 evtdate 是 date；表达式若使用带时区时间，影响结果的条件会不同。

IMMUTABLE 要求相同参数始终得到相同结果；STABLE 只承诺同一条语句内的结果稳定。日期格式化函数可能涉及类型转换、时区或格式设置，数据库不会因为某次调用看起来稳定就放宽生成列要求。

可以用下面的只读查询查看当前数据库中 to_char 的各个重载：

SELECT p.oid::regprocedure AS function_signature,
       p.provolatile
FROM pg_proc AS p
JOIN pg_namespace AS n ON n.oid = p.pronamespace
WHERE n.nspname = 'pg_catalog'
  AND p.proname = 'to_char'
ORDER BY p.oid::regprocedure::text;

provolatile 中，i 表示不可变，s 表示稳定，v 表示易变。要对照实际匹配的参数类型，不能从另一种重载推断当前调用符合条件。date 传入格式化函数时还可能经过隐式转换，因此源列是日期也不足以证明整个表达式不可变。

展示文本放在查询里，保留日期原值

如果新增字段只是为了报表或接口显示，通常可以保留日期列，在读取时格式化。下面是无需业务表的只读示例：

SELECT date '2026-10-12' AS evtdate,
       to_char(date '2026-10-12'::timestamp,
               'YYYY-Mon-DD') AS display_date;

这里显式转为不带时区的 timestamp，并把输出命名为展示文本。它是普通查询表达式，不受生成列的不可变限制。实际查询可对自己的日期列采用同样的展示方式，或在应用层按接口约定格式化；保存、排序和日期运算仍使用原日期列。

这项调整不会创建一个可直接写入或建立普通列索引的实体字段。下游若原本期待数据库返回 chardate 列，需要同步修改查询或映射，并核对别名、返回类型和格式约定。不能只删去失败的迁移步骤，却让应用继续读取尚不存在的列。

如果只是月份和分钟位置写错，应另查日期格式模板中的 MM 与 MI。那会产生错误文本，与本页的建列阶段限制不同。

必须保存文本时，再决定维护方式

若外部协议确实要求保存一份文本快照，先定义它是“写入时的固定文本”，还是每次都应随日期变化。普通文本列由应用或触发器维护，与生成列的自动计算语义不同；需要覆盖所有写入入口、日期更新、历史回填和失败回滚，不能只补一个默认值。默认值也不能直接引用同一行的其他列。

不要只把包装函数标为 IMMUTABLE 来消除错误。这个标记是给优化器的承诺，并不冻结时区、语言设置或函数内部行为。固定输入类型和格式的包装函数有时可以成立，但需要逐项核对真实依赖，并承担以后修改函数实现、重算已有数据的维护责任；不应把任意日期格式化函数统一改成不可变。

采用查询时格式化后，验收失败的建列步骤已从迁移中正确调整，应用能读取约定字段，原日期值保持不变。日期为空、跨年及不同连接设置也应按接口要求核对。回退展示改动时恢复原查询和应用映射；不要为了回退一个显示字段删除日期数据。