你以为的PostgreSQL支持的表名最长长度是多少？

256个字符？还是512个字符？先别急着下结论。

这里不妨先卖个关子。

大家可能都听说过那个经典的运维梗：在Linux中执行 rm -rf ${LOG_DIR}/，因为变量LOG_DIR为空，命令变成了rm -rf /，结果导致根目录被清空。其实，数据库操作里也藏着类似的“陷阱”。最近就遇到一个真实案例：本想删除一个过期的日志表，却因为表名超长被系统静默截断，最终误删了不该动的表。

下面，我们就来一步步还原这个踩坑现场。

第一步

首先，创建一个模拟的“正式表”。

-- 正式表建表语句
create table t_loooooooooooooooooooooooooooooooooooooooooong_name (name varchar(10));

第二步

接着，按照常见的备份逻辑，将这张正式表重命名为一个带日期的备份表。

alter table t_loooooooooooooooooooooooooooooooooooooooooong_name rename to t_loooooooooooooooooooooooooooooooooooooooooong_name_bak_20260303;

命令执行成功了。但仔细一看，屏幕上却多出了一行提示：

identifier "t_loooooooooooooooooooooooooooooooooooooooooong_name_bak_20260303" will be truncated to "t_loooooooooooooooooooooooooooooooooooooooooong_name_bak_202603"

看到了吗？系统明确告诉你，标识符被截断了。但悲剧的是，这个警告往往被忽略，操作依然“成功”执行了。

第三步

然后，我们需要根据备份表的结构，重建一张新的正式表。你猜这一步能成功吗？

答案是：能。而且，同样的截断提示会再次出现。

create table t_loooooooooooooooooooooooooooooooooooooooooong_name (like t_loooooooooooooooooooooooooooooooooooooooooong_name_bak_20260303 including all);

第四步，重要的一步来了

假设现在要实施日志滚动清理，需要删除更早的备份表（比如20260302）。这里存在一个隐含前提：20260302的表暂时还不存在，因为滚动逻辑是新的。

于是执行删除命令：

drop table t_loooooooooooooooooooooooooooooooooooooooooong_name_bak_20260302;

结果可想而知。这条命令同样被截断执行了，但它删除的不是那个“不存在的”20260302表，而是被截断后实际存在的表——t_loooooooooooooooooooooooooooooooooooooooooong_name_bak_202603。也就是说，刚刚备份出来的数据，转眼就被自己人误删了。

结论

那么，截断后的表名到底有多长呢？我们来实测一下：

select length('t_loooooooooooooooooooooooooooooooooooooooooong_name_bak_202603');
length|
------+
    63|

答案揭晓：只有63个字符。是不是比想象中短得多？

总结

其实，这个特性在PostgreSQL官方文档的 Identifiers and Key Words 一节中有明确说明。原文是这么写的：

The system uses no more than NAMEDATALEN-1 bytes of an identifier; longer names can be written in commands, but they will be truncated. By default, NAMEDATALEN is 64 so the maximum identifier length is 63 bytes. If this limit is problematic, it can be raised by changing the NAMEDATALEN constant in src/include/pg_config_manual.h.

简单翻译一下：系统标识符的字节长度不能超过 NAMEDATALEN-1。默认情况下，NAMEDATALEN 是64，所以最大长度就是63字节。命令中可以写入更长的名字，但超出的部分会被静默截断。

这里有两点需要特别警惕：

第一，文档说的是字节数，而不是字符数。对于多字节字符（比如中文），实际能使用的字符数会远少于63个。

第二，这个限制能改吗？理论上可以，但非常麻烦。因为它是一个编译期常量，意味着你必须重新编译PostgreSQL源码才能修改。对于绝大多数使用预编译发行版的用户来说，这基本等于“改不了”。

最后必须强调，这个限制不仅适用于表名，而是适用于所有标识符，包括字段名、视图名、索引名等等。在设计和命名时，务必把这个63字节的“隐形天花板”放在心上。

参考

PostgreSQL: Documentation: 18: 4.1. Lexical Structure