Re: Errors when restoring backup created by pg_dumpall

On 12/9/24 14:31, David G. Johnston wrote:
> On Mon, Dec 9, 2024 at 3:14 PM PopeRigby <poperigby@mailbox.org> wrote:
>
>     On 12/7/24 11:58, David G. Johnston wrote:
>>     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.
>>
>     Yeah, that was a typo. It seems weird that this behavior would be
>     broken by default though, is there anything that could fix it
>     upstream?
>
>
> You saw and tried the work being done "upstream" to fix the situation. 
> It's a big knot in the system and it isn't easy (or highly motivated) 
> to untangle unfortunately...
>
> David J.
>
Understood. Well, at least it was a fairly easy fix. Thanks for the help :)