Re: Errors when restoring backup created by pg_dumpall
От | David G. Johnston |
---|---|
Тема | Re: Errors when restoring backup created by pg_dumpall |
Дата | |
Msg-id | CAKFQuwZf+1frb+82G2-2tD84GXEpuCG_WZaiAU46=L2PDa9gYw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Errors when restoring backup created by pg_dumpall (PopeRigby <poperigby@mailbox.org>) |
Ответы |
Re: Errors when restoring backup created by pg_dumpall
|
Список | pgsql-general |
On Sat, Dec 7, 2024 at 12:25 PM PopeRigby <poperigby@mailbox.org> wrote:
It actually looks like setting those all to have public fixed all the
errors, including the one with lldap. So, how can I get it to not put
public there automatically for next time?
I assume you mean "get it to put public there" (i.e., the "not" is a typo)
You cannot. The security team has decided to not permit an opt-in bypass of the lock-downs implemented to fix CVE-2018-1058.
Your only real choice at the moment is to replace the function call in the generated expression with a custom function and in that custom function's create function command attach a "set search_path to public" clause. That will prevent inlining and also ensure the public schema is in the search_path when executing the public.ll_to_earth function call. With that in place the empty search_path in the dump file will no longer matter.
David J.
В списке pgsql-general по дате отправления: