PostgreSQL仅用public schema时，含嵌套函数检查约束的表pg_restore导入失败

问题复现 #

你遇到的这个情况很典型：在只使用public schema的PostgreSQL环境里，当表的CHECK约束用到嵌套了其他函数的自定义函数时，pg_dump导出后用pg_restore恢复会失败；但如果CHECK约束里的函数是独立的（没调用其他函数），恢复就完全正常。而且这个问题是在9.3.22升级到9.3.23、9.4.16升级到9.4.17之后才出现的，旧版本完全没问题。

根因分析 #

这个问题的核心是PostgreSQL在这几个小版本更新中做了**search_path的安全变更**——为了避免不安全的schema依赖（比如恶意利用默认search_path执行未授权函数），官方调整了恢复等操作场景下的默认search_path行为。

当恢复数据时，数据库会验证CHECK约束，而如果约束里的函数还调用了其他函数，此时由于search_path的限制，数据库无法找到被嵌套调用的底层函数（哪怕它们都在public schema里），直接导致约束验证失败，进而中断导入流程。

解决方案 #

针对你的场景（仅使用public schema），有几个靠谱的解决办法：

1. 导出/恢复时显式指定search_path #

在使用pg_dump导出时，通过--set参数强制指定search_path为public：

pg_dump -d your_database_name -n public --set=search_path=public > backup.sql

恢复的时候也同步指定：

pg_restore -d your_database_name --set=search_path=public backup.dmp

或者在恢复前，先连接数据库执行：

SET search_path = public;

再执行恢复操作。

2. 给所有函数定义加上schema前缀 #

修改CHECK约束里用到的函数，以及它们调用的所有底层函数，在定义时显式加上public.前缀。比如把原来的：

CREATE FUNCTION validate_value(val INT) RETURNS BOOLEAN AS $$
BEGIN
  RETURN check_range(val); -- 调用另一个函数
END;
$$ LANGUAGE plpgsql;

改成：

CREATE FUNCTION public.validate_value(val INT) RETURNS BOOLEAN AS $$
BEGIN
  RETURN public.check_range(val); -- 显式指定schema
END;
$$ LANGUAGE plpgsql;

这样不管search_path怎么变，数据库都能精准找到对应的函数，从根源上避免依赖问题。

3. 调整数据库默认search_path（适合长期环境） #

如果是固定使用的环境，可以修改数据库的默认search_path：

ALTER DATABASE your_database_name SET search_path = public;

这个方法更适合全局配置，临时恢复场景还是前两种更灵活。

注意事项 #

这个变更是PostgreSQL的安全增强特性，建议后续定义所有数据库对象（表、函数、约束等）时，都显式指定public schema，不要依赖默认的search_path设置，这样能避免类似的兼容性问题。

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