目前已知方法（可根据自己实际需要选择适合自己的）
1. 在连接中直接使用set search_path to xxx是可以针对本连接生效的，但是弊端就是仅对当前连接生效，重新连接数据库则被还原了。
2. 若想持久化的修改某个数据库中search_path可以使用alter database databaseName to xxx（直接修改postgres.conf跟这里效果应该是一样的）;然后重启数据库或重新加载配置即可实现所有连接均使用新配置。
3. 可以针对某个角色来配置search_path，alter role roleName search_path = xxx;
今天生产环境出现一个很怪异的问题：Navicat中调用自定义函数select datediff('day', now()::timestamp, now()::timestamp)报错函数不存在，但是直接使用psql -d登录后台可以执行同样的脚本。
经过确认这个函数在public中是存在的。但继续排查发现Navicat中show search_path不存在public模式，在psql -d中是存在的。
那么现在可以确定是因为这个search_path配置不正确导致该错误发生。这还不简单，直接alter database就行了嘛，于是开干，真正开始上手才发现自己too simple, too naive。
先试验在Navicat中set serach_path，不生效；
再试验alter database search_path，不生效；
难道是在postgres.conf里面写死了？查看该文件发现参数是注释的。解禁并修改为想要的，重启数据库，不生效；
这TMD就不科学了，还有其他方法可以修改系统配置吗？去看看select name, setting from pg_settings where name = 'search_path';发现结果是没修改以前的，直接更新这个系统视图说没权限。这TMD真没办法了呀！
既然psql -d是正常的，那说明Navicat肯定是有地方设置的不对呀，但是现在能改的设置都改了，还怎么改？
经过N谷歌，发现了上面的第三种方法，alter role。难道alter database不应该比alter role级别更高吗？整个数据库都变了，角色竟然不变？
不管他，死马当活马医，先试试再说。成了！他成功了！竟然成功了！！！这！！！恩，看来GP还是很人性化的，在提供顶层统一配置的同时，还允许来个私人订制。恩，这很GP！！！
PS：这个错误是一个运行了两三年的系统突然在这两天出现的，项目组近期也没对数据库做过什么升级，突然就这样了，为什么？怀疑是因为别的项目组在执行升级脚本时更改了公用账户的权限（这个库还有其他项目组在用），所以大家以后再进行数据库操作，尤其是涉及到这种高级别控制的操作，一定要慎之又慎，想了又想，测了又测。不然，哼哼，被打PP的可不会是我！！！
后记：经公司大牛提醒，想起来可以通过pg_settings视图中的source列来确定参数值来源，上述环境定位问题时直接查询该视图即可快速定位问题原因。