科技 · 实用指南
PostgreSQL 提示 relation does not exist？先指纹化失败会话再改 search_path
SQLSTATE 42P01 常见原因是应用与管理终端在不同数据库、schema 或会话中解析名称。先在失败连接执行只读探针，再只修复已证明的分支。
pgAdmin 或 psql 能看到表，应用仍可能报 relation does not exist。关键不是“有人看见了表”，而是失败会话实际连接了哪台服务器、哪个数据库、角色和搜索路径。
不要先重建表、全局修改 search_path 或广泛授权。应在原应用连接中保存错误和 SQLSTATE，并采集只读会话指纹。
采集准确的失败会话
通过产生 42P01 的同一连接池、事务与角色运行指纹，记录数据库、服务端地址端口、用户、角色、search_path 和 current_schemas(true)。
逐字保存原 relation 名称、引号、schema 限定和 SQLSTATE；管理终端也采集同样指纹。
不改变状态地解析名称
对原始未限定名称和预期 schema 限定名称分别调用 to_regclass，再联查 pg_class 与 pg_namespace，记录 relkind、持久性和可见性。
两种写法均为 NULL 且目录无匹配，优先排查错误数据库、未执行或回滚迁移、已删除对象或其他会话的临时表。
分离大小写、可见性与权限分支
把目录拼写与 SQL 标记比较。创建为 "Orders" 的对象必须按相同大小写引用。
限定名称存在但访问失败时分别检查 schema USAGE 与表权限；API 暴露规则又是另一分支，不能用广泛授权替代诊断。
对比迁移或管理会话
在真正创建对象的迁移工具或事务内运行同一指纹，比较主机、端口、数据库、角色和有效 schema。
核对迁移历史和提交状态；未提交 CREATE、失败迁移、不同租户 schema 或临时表都不能靠改 search_path 修复。
实施一个窄修复并闭环验证
若应用应始终访问一个对象，使用 schema 限定名；若确实依赖未限定名，则审查角色或连接初始化配置并重连连接池。
混合大小写重命名要用协调迁移，权限只授所需；确认迁移目标前不要重建同名表。最后用新的应用连接重跑指纹和原语句。
