PostgreSQL 表名有大写字母，查询报 relation does not exist

管理工具中能看到名为 TEST 的表，查询表清单也能找到它，执行下面的语句却报错：

SELECT * FROM TEST;

ERROR: relation "test" does not exist

留意报错里的名字：输入是大写 TEST，服务器查找的却是小写 test。PostgreSQL 会把没有双引号的标识符折叠成小写。如果实际对象是用双引号创建的 "TEST"，它和小写 test 是两个不同的名字。

这篇文章处理的是表确实存在，但引用时丢失了大小写或 schema 的情况。relation does not exist 还可能出现在连错数据库、对象尚未创建等场景，不能只看到这句错误就给所有名字加引号。以下 SQL 在已经连接目标数据库的查询窗口或 psql 中使用；示例的 public、TEST 和 Col1 都需按实际对象替换。

先核对连接与实际名称

在发生报错的同一个连接中查看当前数据库、执行身份和搜索路径：

SELECT current_database(), current_user;
SHOW search_path;

同一台 PostgreSQL 服务器可以有多个数据库，管理工具里展开的数据库也不一定就是当前查询窗口连接的数据库。先对齐连接，避免在错误的库里反复修改 SQL。

接着按原样读取表名，不要先转成小写：

SELECT table_schema, table_name, table_type
FROM information_schema.tables
WHERE table_schema NOT IN ('pg_catalog', 'information_schema')
ORDER BY table_schema, table_name;

假如结果中有 schema 为 public、表名为 TEST 的一行，后面的查询就应保留这个大写拼写。这里返回的是名称的值，双引号作为 SQL 定界符，不会额外存成名称的一部分。因此清单里显示 TEST 而不是 "TEST"，并不表示大小写信息丢失了。

这个视图只展示当前数据库中当前用户有权访问的表和视图。没有查到对象时，应继续核对数据库、角色和建表状态，不能直接下结论说表已经被删除。能看见清单中的名称，也不保证当前角色拥有读取整张表所需的 SELECT 权限。

对已有对象，保留精确拼写并限定 schema

如果清单确认对象是 public 中的 TEST，可以先用下面的查询验证名称与权限，不读取实际数据行：

SELECT * FROM "public"."TEST" LIMIT 0;

名称解析正确且具有所需权限时，查询会成功返回列结构，但没有数据行。需要核对业务数据时，再使用经过确认的列和筛选条件；不要为了验证一个表名就读取整张大表。

双引号要分别包住 schema 和表名。"public"."TEST" 表示 schema 中的表；"public.TEST" 则是一个包含点号的完整标识符，不是同样的引用。若实际 schema 叫 AppData，也要保持大小写，写成 "AppData"."TEST"。

未限定 schema 的表名会按 search_path 查找。目标表即使存在于另一个 schema，也可能因不在搜索路径中而无法找到。直接限定实际 schema，可以缩小查找范围，也避免为了排错改动整个角色或数据库的默认搜索路径。

不要把表名改用单引号。单引号用于字符串值，双引号用于标识符。比如清单查询中的 table_name = 'TEST' 是拿名称值做比较，而 FROM "TEST" 才是在引用对象。

小写名称也可以用双引号引用：test、TEST 和 "test" 都指向小写名称；"TEST" 保留大写，指向的是另一个名称。关键是与数据库存储的拼写一致，不是判断这个对象“当初有没有用过引号”。

表名修好后，列名也要按实际值引用

如果表能找到，但随后报 column "col1" does not exist，检查列名是否同样包含大写字母：

SELECT column_name, ordinal_position
FROM information_schema.columns
WHERE table_schema = 'public'
  AND table_name = 'TEST'
ORDER BY ordinal_position;

这条查询也受当前用户的可见权限限制。若实际列名是 Col1，查询写为：

SELECT "Col1" FROM "public"."TEST" LIMIT 0;

这里不能写成未引用的 Col1，因为它会被折叠成 col1。修复标准是正确的表和列都能解析，不能只确认最初那条表不存在错误消失。

从元数据生成 SQL，用 quote_ident 处理每个名字

读取第三方数据库时，程序往往无法控制建表方式。把查询结果中的表名直接拼进 SQL，会在大写、空格、保留字或名称内含双引号时出错。也不要先把所有表名转小写；那会改变本来要访问的对象。

可以让 PostgreSQL 为每个名称生成合适的标识符写法：

SELECT table_schema,
       table_name,
       quote_ident(table_schema) || '.' || quote_ident(table_name) AS sql_name
FROM information_schema.tables
WHERE table_schema NOT IN ('pg_catalog', 'information_schema')
ORDER BY table_schema, table_name;

quote_ident 只在需要时添加双引号，并正确处理名称内部的双引号。返回小写 public 而不是 "public" 是正常的，两种写法在这里含义相同。应分别处理 schema 和表名，再用点号连接；把 public.TEST 整串交给它，会把这串文本当作一个名称。

如果需要生成可人工检查的探测语句，可以只生成文本，不立即执行：

SELECT 'SELECT * FROM '
       || quote_ident(table_schema) || '.' || quote_ident(table_name)
       || ' LIMIT 0;' AS check_sql
FROM information_schema.tables
WHERE table_schema = 'public'
  AND table_name = 'TEST';

这会返回 SQL 字符串，不会自动查询目标表。先核对生成的完整名称，再交给执行逻辑。应用自身构造 SQL 时，使用数据库驱动或查询构建器提供的标识符引用功能；数据值继续使用参数绑定。标识符和数据值是不同的语法位置，不要用给字符串值转义的办法替代表名引用，也不要为修复名字而取消值参数化。

不必为消除报错立即重命名表

对已有数据库，修正引用通常比改表名影响更小。表名可能已被应用 SQL、ORM 映射、报表和运维脚本使用，直接统一改成小写会让其他调用方找不到原来的对象。若确有命名规范迁移需求，应另行清点依赖并安排变更，不能作为本次查询报错的快捷修复。

本次处理只涉及读取元数据和调整查询文本。修改应用或报表前保留原版本；验证后若出现新的权限、连接或字段错误，恢复相关查询改动并按新错误定位，不要重建同名表、删数据或授予超出需求的权限。

最终应在原来出错的账户与连接环境中，确认数据库正确、限定名称指向预期 schema，表和列的大小写都保持原样。若采用元数据生成 SQL，还需检查生成结果，而不能只检查表清单的显示样式。