PostgreSQL表名超长踩坑记

 更新时间:2026年05月06日 09:22:17   作者:小瓦码J码  
本文介绍了PostgreSQL表名最长长度为63个字符,而非常见的256或512个字符,并以删除过期日志表为例,详细描述了表名被截断执行导致误删的问题及其解决方法

你以为的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暂时还不存在,因为这是个新逻辑。

执行下面的SQL命令:

drop table t_loooooooooooooooooooooooooooooooooooooooooong_name_bak_20260302;

结果你应该能想到,又被截断执行了。并且把表t_loooooooooooooooooooooooooooooooooooooooooong_name_bak_202603删除了。也就是说,这个表刚刚备份出来就被删除了。

结论

来看一下,截断后的表名有多长。测试SQL如下:

select length('t_loooooooooooooooooooooooooooooooooooooooooong_name_bak_202603');

length|
------+
    63|

想不到吧,只有63个字符。

总结

关于这个特性,官方文档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,具体是多少?就是 64-1=63

需要注意的是,原文中提及了对于多字节字符,比如中文名称,肯定达不到63,因为是按字节数算的。

我可以修改配置吗?增大范围。

不好意思,改不了,这个是编译期常量。如果你要自己编译一个版本是可以的。上面的原文引用已经列出的源码的修改位置了。

注意:官方说的是标识符,没说表名。也就是说类似,字段名、视图名等等都是适用的。

参考

PostgreSQL: Documentation: 18: 4.1. Lexical Structure

到此这篇关于PostgreSQL表名超长踩坑记的文章就介绍到这了,更多相关PostgreSQL表名超长内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家!

相关文章

  • PostgreSQL部署逻辑复制过程详解

    PostgreSQL部署逻辑复制过程详解

    这篇文章主要介绍了PostgreSQL部署逻辑复制过程详解,本文给大家介绍的非常详细,对大家的学习或工作具有一定的参考借鉴价值,需要的朋友参考下吧
    2024-04-04
  • PostgreSQL如何根据字符串的长度排序

    PostgreSQL如何根据字符串的长度排序

    在PostgreSQL数据库中,可以通过LENGTH函数获取字符串的长度,并据此进行排序,LENGTH函数会计算并返回字符串的字符数量,要根据字符串长度进行升序排序,可以在SQL查询中直接使用LENGTH函数,本文介绍PostgreSQL如何根据字符串的长度排序,感兴趣的朋友一起看看吧
    2024-11-11
  • postgresql之greenplum字符串去重拼接方式

    postgresql之greenplum字符串去重拼接方式

    这篇文章主要介绍了postgresql之greenplum字符串去重拼接方式,具有很好的参考价值,希望对大家有所帮助。如有错误或未考虑完全的地方,望不吝赐教
    2023-05-05
  • PostgreSQL优雅的进行递归查询的实战指南

    PostgreSQL优雅的进行递归查询的实战指南

    在实际开发中,我们经常会遇到树形结构或图结构的数据需求,这些场景的核心问题是:如何高效查询具有层级/递归关系的数据?所以本文将从基础到实战,手把手教你掌握递归查询的精髓,需要的朋友可以参考下
    2026-01-01
  • PostgreSQL索引的设计原则和最佳实践

    PostgreSQL索引的设计原则和最佳实践

    本文详细介绍了PostgreSQL索引设计的核心原则和最佳实践,本文将从 索引类型选择、列顺序设计、复合索引策略、部分索引应用、统计信息管理、反模式识别 六大维度,深入剖析 PostgreSQL 索引设计的核心原则,并提供可落地的最佳实践,感兴趣的朋友跟随小编一起看看吧
    2026-01-01
  • PGSQL查询最近N天的数据及SQL语句实现替换字段内容

    PGSQL查询最近N天的数据及SQL语句实现替换字段内容

    PostgreSQL提供了WITH语句,允许你构造用于查询的辅助语句,下面这篇文章主要给大家介绍了关于PGSQL查询最近N天的数据及SQL语句实现替换字段内容的相关资料,文中通过实例代码介绍的非常详细,需要的朋友可以参考下
    2023-03-03
  • postgresql 导入数据库表并重设自增属性的操作

    postgresql 导入数据库表并重设自增属性的操作

    这篇文章主要介绍了postgresql 导入数据库表并重设自增属性的操作,具有很好的参考价值,希望对大家有所帮助。一起跟随小编过来看看吧
    2021-01-01
  • 浅谈PostgreSQL的客户端认证pg_hba.conf

    浅谈PostgreSQL的客户端认证pg_hba.conf

    这篇文章主要介绍了浅谈PostgreSQL的客户端认证pg_hba.conf,具有很好的参考价值,希望对大家有所帮助。一起跟随小编过来看看吧
    2021-01-01
  • 无公网IP环境下的PostgreSQL远程访问方案

    无公网IP环境下的PostgreSQL远程访问方案

    本文提出了一种基于内内网穿透技术的PostPostQL远程访问解决方案,该方案无需公网IP,配置简单且安全性可控,支持扩展性强,通过三步实现:隧道建立、端口映射和身份验证,实测延迟5-ms、带宽NMbps,适用于开发、数据查询和报表导出场景,需要的朋友可以参考下
    2026-04-04
  • PostgreSQL function返回多行的操作

    PostgreSQL function返回多行的操作

    这篇文章主要介绍了PostgreSQL function返回多行的操作,具有很好的参考价值,希望对大家有所帮助。一起跟随小编过来看看吧
    2020-12-12

最新评论