Na vicat 连 PostgreSQL 无 SQL 补全是因默认关闭该功能，需手动启用并刷新元数据；补全依赖本地缓存而非服务端，支持离线使用，但函数和操作符补全有限且不校验语义。
Na vicat 连 PostgreSQL 为啥没 SQL 补全？
这事儿得先澄清一个常见的误解：问题不在 PostgreSQL 身上，它本身是支持相关功能的。真正的症结在于，Na vicat 为了追求连接速度和简洁性，默认把这个“自动完成”功能给关掉了。而且，它的补全机制完全是“自力更生”，不依赖数据库服务端的任何能力，纯粹是客户端的本地行为。
那么，补全用的数据从哪儿来呢？答案是你本地的缓存。Na vicat 会自己缓存连接过的数据库表结构、字段名、内置函数列表等信息。这就带来了一个有趣的特点：哪怕你连接的是个只读副本，甚至完全断网，只要之前成功连接并加载过元数据，SQL补全依然可以正常工作。这算是一个离线福利吧。
如果你遇到了以下情况，那大概率就是补全功能没开：输入 SELECT * FROM user 后按 Tab 键毫无反应；或者在 WHERE created_ 后面，怎么也等不到 created_at 字段的提示；再比如，输入函数如 COALESCE( 时，参数列表弹不出来。
- 第一步，确认开关已打开：右键点击你的连接 -> 选择「编辑连接」-> 切换到「高级」页签 -> 找到并勾选上
Enable auto completion这个选项。 - 第二步，手动刷新元数据：功能开启后，通常需要手动触发一次元数据加载。再次右键点击连接 -> 选择「刷新」-> 然后观察状态栏，等待「Refreshing objects…」的提示完成。这个过程有时需要几秒钟，耐心等一下。
- 注意过滤器的干扰：如果你在连接属性里只指定了某个特定的 schema（比如设置了
search_path = 'app'），但补全列表还是空空如也，那就得检查一下「对象过滤器」了。看看是不是误勾选了「仅显示当前 schema」，而当前 schema 又恰好没选对。临时取消这个勾选，再刷新试试。
PostgreSQL 函数和操作符补全为什么总缺几个？
这是 Na vicat 补全功能的一个固有局限。它的函数补全列表并非动态从数据库的 pg_proc 系统表中读取，而是一个静态的内置列表。所以，里面只包含了那些最常用、最经典的函数，比如 COALESCE、TO_CHAR、JSONB_AGG 等。
这意味着什么呢？首先，你自己创建的自定义函数，默认是不会出现在补全列表里的。其次，对于一些较新 PostgreSQL 版本才加入的特性函数，比如 PG 15 里 GENERATE_SERIES 的新参数重载，也可能因为内置列表没及时更新而提示不到。
操作符的补全情况就更弱一些。像 JSONB 包含操作符 @>、全文检索操作符 @@ 这类相对“非标准”的符号，Na vicat 基本不会提示，因为它内部可能将这些归类为特殊符号而跳过了索引。
- 想让自定义函数被补全？ 目前唯一的办法是手动将它们添加到用户函数库：点击菜单栏的「工具」->「选项」-> 找到「SQL 编辑器」-> 选择「用户定义函数」-> 点击「+」号，然后按照格式（例如
my_func(text, int) → text）添加函数名、返回类型和参数列表。 - 补全不负责语义校验：这一点必须清楚。当你遇到类似
ERROR: operator does not exist: jsonb @> text这样的类型匹配错误时，别指望补全功能能帮你提前规避。它只负责“提名”，不负责“审查”操作是否合法。 - 扩展函数的支持：通过 PostgreSQL 扩展安装的函数，比如
postgis、pg_trgm里的那些，默认也不会进入补全列表。要么手动导入，要么只能等待 Na vicat 在后续版本中更新它的内置函数库。
补全延迟高 / 卡住光标 / 提示错乱怎么办？
这类问题的根源，通常在于 Na vicat 后台那个异步加载元数据并构建本地索引的机制。一旦这个本地缓存出了问题，或者你连接的数据库 schema 数量太多、对象太复杂，又或者存在一些带特殊字符的标识符、权限不足导致部分视图无法被解析，补全线程就很容易被“卡住”。
典型的表现有：输入 SELECT 之后，光标要停顿两三秒，表名列表才慢吞吞地弹出来；输入 users. 后字段提示不出来，但如果你把 users.id 完整敲完再删掉 .id，所有字段又突然全部刷出来了；甚至补全菜单里还混杂着已经被删除的表名。
- 终极手段：清空本地缓存：关闭所有 Na vicat 窗口 -> 找到并删除缓存目录。在 Windows 上是
%APPDATA%\PremiumSoft\Na vicat\cache\，在 macOS 上是~/Library/Caches/PremiumSoft/Na vicat/cache/-> 删除后重启 Na vicat。 - 连接时优化加载策略：如果你的数据库里有超级大的 schema（比如超过500张表），建议不要在连接属性里开启「自动加载所有对象」。路径是：编辑连接 ->「高级」-> 取消勾选
Load all objects on connect。改为在左侧对象树里，需要时再手动展开具体的 schema。 - 检查表标识符：如果某张表的字段补全始终缺失，不妨检查一下这张表的列名是否包含了空格、双引号或反斜杠这类特殊字符。Na vicat 对这类非标准标识符的解析有时不太稳定。解决办法？要么考虑重命名列，要么在写 SQL 时手动用双引号将表名引起来，比如
SELECT * FROM "my table"。
Na vicat 补全和 psql \set COMP_KEYWORDS ON 有啥区别？
这完全是两套不同的体系，可以说有根本性的区别。psql 是 PostgreSQL 的原生命令行工具，它的补全基于当前连接的实时元数据，再加上内置的关键词词典，底层走的是 PostgreSQL 自家的 libpq 协议支持。
而 Na vicat 呢？它是一个独立的图形化客户端，补全引擎是自己实现的，位于 GUI 应用层。它不调用 PostgreSQL 的任何补全接口，因此也完全不受 psqlrc 配置文件或者 \set COMP_KEYWORDS ON 这类会话设置的影响。
这个区别带来的直接后果就是：你在 psql 里能轻松补全的自定义函数，在 Na vicat 里默认看不见；反过来，Na vicat 内置补全列表里的一些系统函数（比如 CURRENT_DATE），psql 默认也不会提示——除非你换用像 pgcli 这类功能更强大的第三方命令行客户端。
- 不要混淆命令空间：千万别在 Na vicat 的 SQL 编辑区里尝试执行
\set COMP_KEYWORDS ON这样的 psql 元命令，它会直接报语法错误：ERROR: syntax error at or near "\set"。 - 根据需求选择工具：如果你重度依赖精准、全面的 SQL 补全，并且主要使用 PostgreSQL，那么或许可以考虑转向专门优化的工具。例如，在终端环境使用
pgcli，或者在图形界面尝试 DBea ver（它开源，且支持插件式的元数据同步）。Na vicat 的补全机制决定了它更适合快速编写简单 SQL，对于复杂的数据库建模或探索性查询，可能就不是最得力的助手了。 - 一个容易踩坑的细节：Na vicat 的补全对标识符的大小写是敏感的。如果你建表时用了双引号强制指定了小写名称（如
"users"），那么在想补全字段时，输入USERS.（大写）是不会触发提示的，必须严格输入users.（小写）才行。
