navicat for postgresql 无法还原大对象（lob），因其仅执行标准 ddl/dml，跳过 lo_import() 等函数；仅支持自身启用“包含大对象”选项导出的 .nb3 文件，或改用 psql/pg_restore。
Navicat for PostgreSQL 无法直接还原含大对象（LOB）的 .nb3 备份，除非该备份在创建时已启用「包含大对象」选项；若用 pg_dump -F p 导出的 SQL 文件含 lo_import() 或 lo_export() 调用，Navicat 会执行失败——它不解析或执行这类函数。
为什么还原大对象经常静默失败
Navicat 的「还原」功能本质是按顺序执行 SQL 语句，但它跳过所有非标准 DDL/DML，比如：lo_import、lo_create、lo_put 等 PostgreSQL 大对象函数。你看到“还原成功”，实际只是建了表、插了普通字段数据，oid 字段可能留空或存了无效值，而真正的大对象文件（如 PDF、图片）根本没写入 pg_largeobject 表。
- 错误现象：还原后查
SELECT lo_unlink(oid)报错 “large objectxxxdoes not exist”；或者应用读取大对象时返回空或损坏内容 - 根本原因：Navicat 不具备大对象二进制流的解析与写入能力，也不调用
libpq的 LO API - 兼容前提：只有 Navicat 自身生成的
.nb3备份，且勾选了「备份大对象」（位于备份设置 → 高级 → 勾选「Include large objects」），才能在还原时一并恢复
用 pg_dump 导出含大对象时必须加 -b 和 -F p
如果必须用命令行导出再交给 Navicat 导入（例如跨版本或需审计 SQL），不能只靠 pg_dump -F p。缺 -b 参数会导致大对象被忽略，即使表里有 oid 字段，dump 文件里也不会生成 lo_import 调用。
-
pg_dump -U user -h host -p 5432 -F p -b -f backup_with_lo.sql mydb—— ✅ 正确：含-b才导出大对象关联逻辑 -
pg_dump -F p -f backup.sql mydb—— ❌ 错误：即使表含oid，大对象内容不会出现在 SQL 中 - 注意：
-b仅对使用oid类型或lo模块显式管理的表生效；若用bytea存小文件，则无需-b，Navicat 可正常导入
Navicat 还原前必须手动检查 SQL 文件是否含大对象操作
打开你准备用于「运行SQL文件」的 .sql，搜索关键词判断是否真含大对象逻辑：
- 搜
lo_import或lo_create：有则说明导出时用了-b，但 Navicat 会跳过这些行 → 还原后大对象丢失 - 搜
INSERT INTO pg_largeobject：极罕见，通常是手工拼的 dump，Navicat 同样不认 - 搜
bytea字段的INSERT：这种可被 Navicat 正常执行，无需额外处理 - 结论：只要 SQL 文件里出现任何
lo_*函数，就别指望 Navicat 能还原大对象——得换方案
真正可行的替代路径只有两条
要么退回命令行用 psql，要么改用 pg_restore（针对 -F c 或 -F d 格式）。Navicat 在这个环节就是个纯 SQL 执行器，没底层 LO 支持。
- ✅ 推荐路径：用
psql -U user -d mydb -f backup_with_lo.sql—— 它能识别并执行lo_import，前提是数据库已启用lo扩展（CREATE EXTENSION IF NOT EXISTS lo;） - ✅ 备选路径：用
pg_dump -F c -b导出，再用pg_restore -U user -d mydb backup.custom恢复 —— 快、原子、支持并行，但 Navicat 完全不参与 - ⚠️ 注意：Navicat 的「数据传输」功能也不能迁移大对象，它只传字段值，不触碰
pg_largeobject表
大对象不是“多几个字节”的问题，它是独立于表存储的二进制块，依赖服务端 LO API 绑定。Navicat 图形界面的设计从没考虑这一层，所以别在它的「还原」按钮上浪费时间验证可行性。
