On 12/9/24 14:31, David G. Johnston wrote:
> On Mon, Dec 9, 2024 at 3:14 PM PopeRigby <poperigby(at)mailbox(dot)org> wrote:
>
> On 12/7/24 11:58, David G. Johnston wrote:
>> On Sat, Dec 7, 2024 at 12:25 PM PopeRigby <poperigby(at)mailbox(dot)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 :)