在 PostgreSQL 中，其他表不需要带 public. 也能直接查，是因为你的数据库中配置了 search_path（对象搜索路径），并且里面默认包含了 public 模式。
当你输入一个不带任何模式前缀的表名（如 SELECT * FROM testtable;）时，PostgreSQL 会按照 search_path 里的顺序，挨个模式去寻找这张表。
为什么偏偏 pg_tables 必须带 public.？
因为 pg_catalog（系统核心模式）的优先级永远是最高的。
无论你的 search_path 怎么配置，PostgreSQL 内部都有一条铁律：它在扫描任何用户自定义模式之前，都会雷打不动地先去 pg_catalog 里找同名的对象。
在你的数据库里，同时存在两个同名的对象：
系统自带的视图：pg_catalog.pg_tables（存储了当前数据库所有的表信息）。
你创建的外部表：public.pg_tables。
当你执行没有前缀的命令时，两者的竞争过程如下：
查 testtable 时：
PostgreSQL 先去 pg_catalog 找 pg_catalog.testtable → 找不到；
接着去 public 找 public.testtable → 找到了！ 于是顺利执行（不需要加 public.）。
查 pg_tables 时：
PostgreSQL 先去 pg_catalog 找 pg_catalog.pg_tables → 找到了！
因为在第一步就匹配成功了，PostgreSQL 会直接采用系统视图，而完全无视你建在 public 下的同名外部表。
如果你想强制告诉数据库"我不要系统的那个，我要我自己建在 public 下的外部表"，你就必须加上前缀显式指定：SELECT * FROM public.pg_tables;。
💡 最佳实践建议
为了避免这种被系统表"截胡"的现象，通常强烈不建议在 public 或任何自定义模式下创建与 PostgreSQL 内置系统表/视图同名的对象（例如 pg_tables、pg_indexes、user、role 等）。
既然你在 \det 中已经建了一个 pg_tables11，建议：
以后查询远程的表信息时，直接使用 SELECT * FROM pg_tables11;（它不需要带 public.，因为系统里没有叫 pg_tables11 的内置表）。
或者将 public.pg_tables 这张容易混淆的外部表直接删掉，避免日后误操作。
你可以输入 SHOW search_path; 来查看你当前的搜索路径配置。如果打算清理或重命名那张冲突的表，需要我帮你写对应的 DROP 或 ALTER 语句吗？
如果你下定决心只要自己建在 public 下的外部表，不带前缀直接输入 pg_tables 就能查到它，在 PostgreSQL 中只有一种办法可以实现：彻底改变 search_path 的默认规则，将 pg_catalog 的优先级强行拉到 public 之后。
虽然 PostgreSQL 默认会将 pg_catalog 放在最前面，但如果你在 search_path 中显式地将 pg_catalog 写在后面，数据库就会听从你的指挥，优先去匹配 public。
🛠️ 解决方案：调整 search_path 顺序
请在你的 psql 终端中运行以下命令：
- 临时生效（仅对当前窗口/会话有效，适合测试）
sql
SET search_path TO public, pg_catalog;
请谨慎使用此类代码。
验证效果：
现在你直接运行 SELECT * FROM pg_tables;，它将不再返回本地系统视图，而是直接去查你绑定的外部表 public.pg_tables 了！
- 永久生效（只对你当前的数据库账号有效，推荐）
如果你不想每次打开终端都设置一遍，可以把这个规则绑定到你当前的本地账号 account1 上：
sql
ALTER USER account1 SET search_path TO public, pg_catalog;
请谨慎使用此类代码。
注：执行完永久生效的命令后，你需要断开当前连接并重新登录才会生效。
⚠️ 一个非常重要的安全警告
把 public 放在 pg_catalog 之前虽然能完美满足你的需求，但在数据库运维中属于高风险操作：
系统命令可能会报错：很多 psql 的快捷命令（如 \d、\dt 等）或运维脚本高度依赖 pg_catalog 的原生行为。如果 search_path 被改了，可能会导致某些元数据查询工具出现奇奇怪怪的报错。
安全风险（"木马"隐患）：如果其他普通用户在 public 下恶意创建了一个和系统函数同名的函数（例如 lower() 或 version()），而你作为管理员使用了这个调整过顺序的账号，你就可能会在不知情的情况下调用了别人写的恶意代码。
既然知道了这个原理，你想怎么操作呢？
需要我帮你把这个设置应用到整个数据库级别（所有登录该库的人都生效），还是只保持在你当前的账号上？
另外，之前报错的 testtable 表在建好 USER MAPPING 后现在可以正常查询了吗？