目前已知方法（可根據自己實際需要選擇適合自己的）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列來確定引數值來源，上述環境定位問題時直接查詢該檢視即可快速定位問題原因。