PostgreSQL中UPDATE结合id_encode()生成带尾空格哈希的异常问题

环境信息 #

• 部署环境：Kubernetes，基于Bitnami PostgreSQL Helm Chart
• 数据库版本：postgres:15.4-alpine3.18
• 自定义扩展：pg_hashids

核心问题 #

• 插入触发器函数myfunc自动生成的哈希值末尾带空格（如zmnb ）
• 拆分执行UPDATE的myfunc_fix生成的哈希值无尾空格
• 数据库存在无实际排序规则版本但已记录版本的警告

可能的根本原因 #

1. 字段类型与隐式转换问题 #

如果ids字段是定长字符类型（比如char(n)）而非varchar(n)或text，PostgreSQL会自动补空格填充到指定长度：

• myfunc在INSERT时直接赋值，可能触发了字段类型的隐式转换：如果pg_hashids返回的字符串长度小于字段定义长度，就会被补空格。
• myfunc_fix是先插入再UPDATE，此时赋值逻辑可能绕过了INSERT阶段的某些隐式转换规则，或者UPDATE对字符串的截断/填充处理更严格。

2. pg_hashids扩展的上下文处理差异 #

pg_hashids在不同执行上下文里的字符串返回逻辑可能有区别：

• 触发器函数内调用时，扩展可能返回带有不可见空白字符的字符串，或者返回值被触发器上下文的额外逻辑截断后补空格。
• 独立执行UPDATE语句时，函数返回的字符串直接赋值，没有经过触发器的额外处理环节。

3. 排序规则配置异常的影响 #

你看到的排序规则版本警告，可能和字符串处理逻辑相关：

• 数据库或字段的排序规则配置异常，可能导致字符串在存储或转换时出现额外空格。
• 比如排序规则的版本不匹配，PostgreSQL在处理字符串时会有额外的字符转换操作，间接导致空格问题。

排查验证步骤 #

• 检查ids字段类型：

  SELECT column_name, data_type, character_maximum_length 
  FROM information_schema.columns 
  WHERE table_name = '你的表名';
  

• 直接测试pg_hashids返回值：

  SELECT hashids_encode(你的测试ID值);
  

  对比触发器内生成的结果，看是否原生返回就带空格。
• 查看触发器函数逻辑：确认myfunc里有没有用::char(n)这类强制类型转换的语句。
• 修复排序规则警告：

  ALTER DATABASE 你的数据库名 REFRESH COLLATION VERSION;
  

  执行后观察警告是否消失，同时测试哈希生成是否正常。

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