Re: Errors when restoring backup created by pg_dumpall - Mailing list pgsql-general

From PopeRigby
Subject Re: Errors when restoring backup created by pg_dumpall
Date
Msg-id 9a7ca237-7696-40e3-9ae6-12bd98c1b86c@mailbox.org
Whole thread Raw
In response to Re: Errors when restoring backup created by pg_dumpall  ("David G. Johnston" <david.g.johnston@gmail.com>)
Responses Re: Errors when restoring backup created by pg_dumpall
Re: Errors when restoring backup created by pg_dumpall
List pgsql-general
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.

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?

pgsql-general by date:

Previous
From: "Zacher, Stacy"
Date:
Subject: RE: tds_fdw DB-Library error: DB #: 20002, DB Msg: Adaptive Server connection failed - RESOLVED
Next
From: "David G. Johnston"
Date:
Subject: Re: Errors when restoring backup created by pg_dumpall