Re: Errors when restoring backup created by pg_dumpall

PopeRigby <poperigby@mailbox.org>

From: PopeRigby <poperigby@mailbox.org>
To: "David G. Johnston" <david.g.johnston@gmail.com>
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:14:04Z
Lists: 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?

Commits

  1. contrib/earthdistance: Use SQL-standard function bodies.