这个问题其实涉及PostgreSQL字符类型的核心差异，以及PHP数据库驱动的处理逻辑，我来给你拆解清楚：

核心原因：char(n) vs varchar(n)的本质区别 #

PostgreSQL里的char(n)是固定长度字符类型，而varchar(n)是可变长度类型，两者的存储和读取逻辑完全不同：

• 当你往char(128)字段存入'hello'时，数据库会自动用空格填充到128个字符的长度来存储——这是固定长度类型的特性，必须占满指定长度。
• 但PostgreSQL的char_length()函数很聪明，它会忽略这些填充的空格，只计算实际有效字符串的长度，所以pgAdmin里查出来是5，而不是128。

PHP驱动的处理逻辑 #

PHP的pg_fetch_array()函数在读取字段值时，会直接返回数据库存储的原始字节数据，也就是包含所有填充空格的完整128长度字符串。驱动不会自动帮你截断这些多余的空格，所以你拿到的就是带空格的'hello '（后面其实跟着123个空格，只是显示时可能只看到结尾的几个）。

解决办法 #

你提到改用VARCHAR类型能解决，这确实是最彻底的方案：

• varchar(n)只会存储实际的字符串内容，不会填充额外空格，不管是在pgAdmin查询还是PHP读取，拿到的都是原始的'hello'。

如果暂时没法修改字段类型，也有两种临时处理方式：

1. 在SQL查询时处理：用trim()函数截断空格

select trim(this_field) as this_field from table

然后PHP读取的就是处理后的值。

2. 在PHP端处理：拿到值后手动截断

$arr = pg_fetch_array(pg_query('select * from table'));
$arr['this_field'] = trim($arr['this_field']);

不过还是更推荐改用varchar(128)，毕竟固定长度的char类型现在很少用于普通业务场景，除非有特殊的字节对齐需求。

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