长期以来，不少中文 PostgreSQL 用户遵循一条经验：不要把 lc_messages 设置为 zh_CN。问题不在数据库对中文的支持，而在于中文消息目录多年无人维护，错误提示与新版本功能逐渐脱节。
这个持续七年的缺口如今已被补上。原本甚至可能从 PostgreSQL 发行版中移除的中文翻译，在七天内完成集中更新，并将随 PostgreSQL 19 回到可用状态。这不只是界面语言变化，也会影响故障排查、日志检索和运维自动化。
七年未更新意味着什么
PostgreSQL 使用消息目录为服务端和客户端工具提供本地化提示。当数据库抛出语法错误、权限错误或约束冲突时，lc_messages 决定用户看到哪种语言。
消息目录长期落后会带来几类实际问题：
- 新增错误消息没有中文翻译，日志中可能中英文混杂。
- 已经修改的英文原文仍对应旧翻译，表达可能不准确。
- 新功能引入的术语没有统一译法，增加检索和沟通成本。
- 翻译覆盖率过低时，维护者可能考虑从发行版中删除该语言。
因此，过去避免 zh_CN 是一种务实的运维选择。它不能解决翻译缺失，却能让日志语言保持一致，也更容易根据英文错误文本搜索资料。PostgreSQL 19 更新消息目录后，这条经验不再需要作为默认规则。
本地化错误消息不等于改变错误语义
启用中文消息不会改变 SQLSTATE、事务行为或错误严重级别。应用程序真正应该依赖的是 PostgreSQL 提供的结构化字段，例如五位 SQLSTATE，而不是某一句中文或英文文本。
以唯一约束冲突为例，应用应判断 SQLSTATE 23505，不应匹配“重复键值违反唯一约束”或 duplicate key value violates unique constraint。翻译会修订，措辞会变化，结构化错误码才是稳定接口。
这一区分对升级到 PostgreSQL 19 尤其重要：人工阅读的日志可以切换为中文，但告警、重试和异常映射不应因为翻译更新而失效。
可以这样验证 PostgreSQL 19 的中文消息
下面的命令适合在测试实例中执行。运行前需要确认操作系统已经生成中文 locale；不同系统可能将其命名为 zh_CN.UTF-8、zh_CN.utf8 或其他形式。
# 查看系统实际提供的中文 locale
locale -a | grep -i '^zh_cn'
# 检查数据库版本以及当前消息语言
psql -X -d postgres <<'SQL'
SHOW server_version;
SHOW lc_messages;
SHOW client_encoding;
SQL
确认 locale 名称后，可以只在当前会话中切换，不必立即修改整个实例：
psql -X -d postgres <<'SQL'
SET client_encoding = 'UTF8';
SET lc_messages = 'zh_CN.UTF-8';
-- 故意访问不存在的表，用于观察本地化错误消息
SELECT * FROM __missing_table_for_i18n_check__;
-- SQLSTATE 与本地化文本相互独立
\set VERBOSITY verbose
SELECT 1 / 0;
SQL
如果服务器接受 SET lc_messages，但输出仍然是英文，应检查 PostgreSQL 安装包是否包含对应消息目录，以及服务器进程是否能识别该操作系统 locale。不要直接假定这是客户端编码问题：client_encoding 控制字符传输，lc_messages 才控制服务端消息语言。
准备在实例级启用时，可以通过配置文件设置：
# postgresql.conf
lc_messages = 'zh_CN.UTF-8'
修改后重新加载配置，并确认实际值：
psql -X -d postgres -c "SELECT pg_reload_conf();"
psql -X -d postgres -c "SHOW lc_messages;"
具体 locale 名称必须以数据库所在主机的 locale -a 输出为准。容器镜像尤其需要注意：精简镜像可能根本没有生成中文 locale。
升级时别忽略日志和监控
消息翻译恢复维护后，中文环境的可用性明显改善，但切换生产日志语言仍需评估现有工具链。
建议在采用 PostgreSQL 19 时检查以下事项：
- 在预生产环境触发语法错误、权限拒绝、唯一约束冲突和连接失败，确认中文显示完整且终端使用 UTF-8。
- 搜索告警规则、日志解析器和运维脚本，移除对英文错误句子的硬编码匹配。
- 应用程序按 SQLSTATE 分类异常，并保留服务端返回的原始消息用于人工诊断。
- 确认日志平台、工单系统和通知渠道可以正确存储和展示中文。
- 混合语言团队可继续保留英文生产日志，同时在开发或桌面工具中使用中文；本地化不是必须全局统一。
一次翻译冲刺之后，维护机制更重要
七年积压在七天内完成，解决了 PostgreSQL 19 发布前的直接问题，也避免了中文消息目录被移除。不过，翻译不是一次性资产。数据库持续增加功能、诊断信息和命令行提示，消息目录也必须随版本演进。
对使用者而言，PostgreSQL 19 是重新评估 zh_CN 的合适节点，而不是无条件切换的信号。先验证操作系统 locale 和发行包内容，再检查监控是否依赖文本，最后根据团队语言习惯决定部署范围。对贡献者而言，持续审阅少量新增消息，比多年后再处理一次大规模积压更可靠。