Re: Errors when restoring backup created by pg_dumpall
David G. Johnston <david.g.johnston@gmail.com>
From: "David G. Johnston" <david.g.johnston@gmail.com>
To: PopeRigby <poperigby@mailbox.org>
Cc: Adrian Klaver <adrian.klaver@aklaver.com>, Tom Lane <tgl@sss.pgh.pa.us>, "pgsql-general@postgresql.org" <pgsql-general@postgresql.org>
Date: 2024-12-09T22:31:52Z
Lists: pgsql-general
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.
Commits
-
contrib/earthdistance: Use SQL-standard function bodies.
- 969bbd0fafc0 18.0 landed
- 3652de36e432 17.3 landed
- 31daa10facec 16.7 landed