PostgreSQL自定义函数内lower()无法转换重音大写字符的异常排查

这个现象不属于PostgreSQL的功能缺陷，是内置name类型的固定设计规则导致的，具体逻辑拆解如下：

• name类型是PostgreSQL专门为存储系统目录元数据（比如表名、列名、函数名这类系统标识符）设计的专有内置类型，并非面向业务场景的通用字符串类型。它的所有字符处理逻辑（大小写转换、排序、等值比较）会强制绑定C区域设置，完全忽略会话层、数据库级配置的collate/ctype参数。无论生产环境配置了多完善的支持重音字符的本地语言环境，只要操作链路涉及name类型，字符转换就会走最基础的C locale规则。
• 你在命令行手动执行lower()/upper()时结果完全正常，是因为手动传入的字符常量默认是text类型，会严格继承当前会话配置的、支持重音字符转换的collate规则，自然能正确处理È这类拉丁扩展字符的大小写映射。但你的自定义函数入参是name类型，内部执行substring()截取字符串时，所有中间值都会保持name类型的collate上下文，最终调用的lower()会被强制切到C locale规则执行。而标准C locale只对ASCII范围内的A-Z做大小写转换，遇到È这类非ASCII的重音大写字符时，根本匹配不到对应的转换规则，就会原样返回，出现你观察到的异常。
• 你把参数和返回值替换为text类型后问题完全消失，本质是切断了name类型带来的强制C locale上下文——text、varchar这类通用字符串类型的字符处理会全程继承会话的collate配置，自然能按照生产环境的正确规则完成重音字符的大小写转换。

你观察到开发环境无异常、生产环境触发问题的差异，并非数据库配置的直接区别，是不同集群初始化时绑定的底层libc库实现差异导致的：

• 部分开发环境使用的旧版libc实现，即使在C locale模式下也会附带处理部分UTF-8编码的重音字符大小写转换，不会严格执行C locale的规则；
• 生产环境使用的标准libc实现会严格遵守C locale的处理规则，只对ASCII字符做大小写映射，因此才会复现这个异常。

之前核对到的两个环境collate配置的差异，是和libc实现差异伴生的现象，并非问题的直接诱因。这也是你之前尝试重启数据库服务没有解决问题的原因——问题的根源是类型的固定设计行为和底层libc的实现逻辑，和服务运行状态无关，重启自然无法改变。

你可以在生产环境直接执行下面的SQL，不需要调用自定义函数就能复现这个异常：

SELECT
  lower('È'::name) AS name类型转换结果,
  lower('È'::text) AS text类型转换结果;

执行结果会清晰展示差异：name类型下的È会原样返回，text类型下的È会正确转换为小写的è。

设计说明：name类型强制绑定C locale的规则是刻意的，目的是保证系统元数据的跨环境一致性——无论数据库部署在什么语言、什么配置的服务器上，系统标识符的处理规则永远统一，避免跨环境迁移时出现元数据匹配异常。面向业务场景的字符串处理，本就不应该使用name类型作为参数和返回值，选用text/varchar才是符合PostgreSQL设计预期的选择。

内容的提问来源于stack exchange，提问作者carles