pg_restore恢复带约束表时报依赖错误 咨询解决方法及pg_dump用法

执行PostgreSQL单表转储恢复，将生产环境表同步到开发环境时，使用如下恢复命令出现异常：
pg_restore --no-owner --no-acl --clean --if-exists -d database dump_file.dump
命令返回依赖冲突报错，提示必须使用CASCADE级联删除依赖对象才能完成删除操作，具体报错信息：

pg_restore: while PROCESSING TOC:
pg_restore: from TOC entry 4066; 2606 30526 CONSTRAINT table1 pkey user
pg_restore: error: could not execute query: ERROR: cannot drop constraint pkey on table public.table1 because other objects depend on it
DETAIL: constraint id_fkey on table public.dag depends on index public.pkey
constraint id_fkey on table public.dag depends on index public.pkey
HINT: Use DROP ... CASCADE to drop the dependent objects too...

对应咨询问题的解答如下：

三种实测可用的方法，无漏查风险：

• 事务探测法（准确度最高）：连接到目标开发库，开启显式事务执行带CASCADE的删除语句，执行完成后立刻回滚，数据库会返回所有会被级联删除的对象完整列表，整个过程不会修改真实数据，无副作用：

  BEGIN;
  DROP TABLE public.table1 CASCADE;
  ROLLBACK;
  

  如果要查询其他类型对象的依赖，替换DROP语句即可，比如查询索引依赖就写DROP INDEX public.pkey CASCADE。
• 系统表查询法：直接查询PostgreSQL内置的pg_depend系统依赖视图，拉取所有和目标对象关联的依赖项：

  SELECT objid::regclass AS 关联依赖对象 FROM pg_depend WHERE refobjid = 'public.table1'::regclass;
  

• 详细日志法：给原有pg_restore命令加上--verbose参数重新执行，报错时会打印完整的依赖链信息，不会像默认输出那样只显示第一个碰到的依赖项。

pg_dump没有内置自动递归抓取所有关联依赖的参数，不过可以通过两种方式实现同等效果：

• 手动补全关联对象列表：先用上述方法找全目标表关联的所有依赖，包括外键关联的其他表、依赖该表的视图、函数、物化视图、自定义类型等，转储时通过多个-t（匹配表、视图）、--function（匹配自定义函数）参数把所有关联对象加入转储列表，比如本次报错中dag表依赖table1的主键，转储时把两个表都加入参数即可：
  pg_dump -h 生产库地址 -U 账号 -d 生产库名 --no-owner --no-acl -t public.table1 -t public.dag -f target_dump.dump
• 反向排除无关对象：如果生产库中不需要同步的表占比很低，就不要用-t指定要转储的表，改用--exclude-table参数指定不需要转储的表，默认转储整个库的所有对象，自然不会缺失依赖关系，适合关联对象太多、手动列全成本高的场景。

额外提示：如果确认开发库中的现有数据不需要保留，直接给原有pg_restore命令加--cascade参数即可，恢复时会自动级联删除所有冲突的依赖对象，不需要提前排查依赖，也不需要重新生成转储文件，是开发环境恢复场景下最省事的方案。

内容的提问来源于stack exchange，提问作者Emmanuel