max_identifier_length 返回的通常是 63。这个数字本身并不特别：关系型数据库都会限制表名、列名、索引名等标识符的长度。真正值得注意的是，PostgreSQL 遇到超长标识符时，默认会把它截断，而不是像 MySQL、SQL Server 或 Oracle 那样直接拒绝整条语句。
这会让 SQL 看起来执行成功，但数据库内部保存的名字已经不是你写下的完整名字。命名规范、迁移工具和自动生成 SQL 如果没有意识到这一点，就可能在很晚的时候才暴露问题。
先确认当前限制
可以在目标数据库中直接查询限制值：
SHOW max_identifier_length;
SELECT current_setting('max_identifier_length') AS max_identifier_length;
默认安装通常会显示 63。这里的单位不是业务开发者通常理解的“字符数”，而是 PostgreSQL 内部标识符长度限制对应的字节数。使用非 ASCII 标识符时，尤其要把编码和字节长度纳入设计判断。
这个设置通常来自 PostgreSQL 的编译时参数 NAMEDATALEN，max_identifier_length 展示的是可用标识符长度，而不是一个可以在普通会话中随意调大的运行时开关。应用设计不应依赖把这个值改大来解决命名问题。
PostgreSQL 的行为：语句可能成功，但名字变了
下面的例子可以直接在一个测试数据库中运行。它创建一个明显超过默认限制的表名，然后从系统目录读取 PostgreSQL 实际保存的名字：
DROP TABLE IF EXISTS this_is_a_very_long_table_name_for_postgresql_identifier_demo_2024;
CREATE TABLE this_is_a_very_long_table_name_for_postgresql_identifier_demo_2024 (
id bigint PRIMARY KEY
);
SELECT
c.relname,
length(c.relname) AS character_length,
octet_length(c.relname) AS byte_length
FROM pg_class AS c
WHERE c.oid = 'this_is_a_very_long_table_name_for_postgresql_identifier_demo_2024'::regclass;
在默认配置下，查询结果中的 relname 会是被截断后的名称，而不是完整输入的名称。regclass 解析也很有用：它让 SQL 直接按照数据库实际登记的关系名查找对象，而不是凭肉眼猜测截断结果。
同样的规则也会影响列名、索引名、约束名、序列名以及其他数据库对象的标识符。自动生成名称的 ORM、迁移框架和 DDL 工具尤其容易触发这个问题，因为它们经常把多个业务词、表名和操作类型拼接成一个很长的名称。
最危险的情况是“截断后重名”
假设两个名字前 63 个字节完全相同，差异只出现在后面。截断后，它们会变成同一个数据库标识符。第二次创建对象时，PostgreSQL 可能报告对象已经存在，但错误信息里的名字往往是截断后的名字，排查者需要回到生成 SQL 的源头才能理解冲突原因。
可以用下面的脚本观察这种命名风险：
DROP TABLE IF EXISTS aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa_one;
DROP TABLE IF EXISTS aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa_two;
CREATE TABLE aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa_one (
id integer
);
-- 这两个输入名的前缀非常接近；实际项目中应避免依赖截断后的结果。
CREATE TABLE aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa_two (
id integer
);
这个示例的重点不是让每个环境都复现完全相同的错误文本，而是说明命名空间中的真实键是“截断后的标识符”。在迁移系统里，如果工具只根据原始长名称判断对象是否不同，却把截断后的名称发送给数据库，就可能出现难以理解的冲突。
把命名约束前移到代码和迁移流程
最可靠的处理方式是：在生成 SQL 之前就限制名称长度，并为过长名称追加稳定、可复现的短哈希。下面是一个可以直接改造的 Python 示例。它按 UTF-8 字节数限制名称，并保留名称前缀，避免简单按 Python 字符数切片导致多字节字符被截断。
import hashlib
def postgres_identifier(*parts: str, limit: int = 63) -> str:
"""Build a deterministic PostgreSQL identifier within a byte limit."""
raw = "_".join(part.strip("_").lower() for part in parts if part)
encoded = raw.encode("utf-8")
if len(encoded) <= limit:
return raw
digest = hashlib.sha1(encoded).hexdigest()[:10]
suffix = f"_{digest}"
prefix_bytes = limit - len(suffix.encode("utf-8"))
# Decode with ignore so the prefix cannot end in a partial UTF-8 sequence.
prefix = encoded[:prefix_bytes].decode("utf-8", errors="ignore")
return f"{prefix}{suffix}"
print(postgres_identifier(
"customer",
"monthly_payment",
"unique_constraint_for_external_billing_reference"
))
这个策略有三个实际好处：名称仍然保留可读前缀；相同输入始终产生相同结果；不同的长名称不容易因为末尾被截掉而意外重名。生产代码还应把 limit 从数据库能力或配置中读取，并对最终结果做断言，而不是永久硬编码默认值。
在 CI 中，也可以对迁移生成的 DDL 做一次检查。下面的 psql 命令会让脚本在发现超长标识符时失败；示例假设迁移 SQL 存放在 migrations/ 目录，实际项目应使用 SQL 解析器或迁移工具提供的结构化接口，以避免把字符串常量误判为标识符。
set -euo pipefail
limit="$(psql "$DATABASE_URL" -Atc 'SHOW max_identifier_length')"
python - "$limit" <<'PY'
import pathlib
import re
import sys
limit = int(sys.argv[1])
text = "\n".join(path.read_text(encoding="utf-8") for path in pathlib.Path("migrations").glob("*.sql"))
# This is only a lightweight guard for generated, unquoted names.
identifiers = re.findall(r"\b(?:table|index|constraint|sequence)\s+([a-zA-Z_][a-zA-Z0-9_]*)", text, re.I)
long_names = [name for name in identifiers if len(name.encode("utf-8")) > limit]
if long_names:
print(f"identifiers exceed PostgreSQL limit ({limit} bytes):", file=sys.stderr)
print("\n".join(sorted(set(long_names))), file=sys.stderr)
raise SystemExit(1)
PY
这类检查不能替代真正的 SQL 解析，但它能在代码评审和部署前提供一个便宜的预警。对使用双引号标识符、复杂 DDL 或 ORM 自动命名的项目，应在生成 DDL 的那一层直接做约束和测试。
采用时的检查清单
把 max_identifier_length 当作数据库契约的一部分，而不是一个可以忽略的展示参数。落地时可以检查以下事项：
- 在每个支持的 PostgreSQL 版本和环境中确认
SHOW max_identifier_length的值。 - 让 ORM、迁移工具、索引和约束命名器按字节长度而不是视觉字符数处理名称。
- 对超长名称采用稳定哈希，避免只保留前缀造成截断后重名。
- 在测试数据库中检查系统目录中的实际对象名，而不是只检查迁移文件里的输入名。
- 记录生成名称的映射关系，让运维人员能从截断或哈希后的名称追溯到业务对象。
- 对跨数据库迁移保持最保守的公共命名长度，因为不同数据库对超长标识符的处理并不一致。
63 只是一个查询结果。真正需要管理的是名称从代码进入数据库之后的变化，以及这个变化如何影响迁移、排障和跨数据库兼容性。把名称生成和长度校验前移，通常比等数据库在生产环境中替你做截断更容易维护。