On 12/9/24 14:47, Adrian Klaver wrote:
On 12/9/24 14:14, PopeRigby wrote:
On 12/7/24 11:58, David G. Johnston wrote:
On Sat, Dec 7, 2024 at 12:25 PM PopeRigby <poperigby@xxxxxxxxxxx>
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.
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 could file an issue here:
https://www.postgresql.org/account/login/?next=/account/submitbug/
Ask if the developers could use the mechanisms available here:
https://www.postgresql.org/docs/current/extend-extensions.html#EXTEND-EXTENSIONS-RELOCATION
to schema qualify the objects in the extension.
Not sure if that will fly or not, but it is worth a shot.
Will do!
