Feedback-ID: i76984098:Fastmail
Message-ID: <5dc9dd9e-a3c9-45a1-8497-7e304812eb8c@aklaver.com>
Date: Mon, 9 Dec 2024 14:47:07 -0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Errors when restoring backup created by pg_dumpall
To: PopeRigby <poperigby@mailbox.org>,
 "David G. Johnston" <david.g.johnston@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
 "pgsql-general@postgresql.org" <pgsql-general@postgresql.org>
References: <6a6439f1-8039-44e2-8fb9-59028f7f2014@mailbox.org>
 <9c5ba566-27b8-4e8c-bf7d-2dc561509991@mailbox.org>
 <CAKFQuwaB5GuUNuyiUbS0ah-LYXepHLPnOHrP7g8RMz8ywOm3zQ@mail.gmail.com>
 <ff94f628-27af-4c3a-9590-cba38bb5d2d1@mailbox.org>
 <CAKFQuwYQUequkYVS8SLgC1L0TOdWNK=xVyxnPD9RPPwfvYRFSQ@mail.gmail.com>
 <41791b6d-aaf5-4fed-9cc3-e89bc49e8637@mailbox.org>
 <CAKFQuwbe4TSU_LxsrGxgcv4DfQq2x-UNoyKx-ABy36PhvbGCdg@mail.gmail.com>
 <1257068.1733025493@sss.pgh.pa.us>
 <06425038-e012-4bac-aec1-d9541436f893@mailbox.org>
 <92405f98-7f0c-4442-8252-697352daefc1@aklaver.com>
 <1470486.1733087658@sss.pgh.pa.us>
 <4ab662d8-57cc-471f-8a58-cfd71d1cea22@aklaver.com>
 <1475512.1733090108@sss.pgh.pa.us>
 <19d5f2c7-1252-4442-accb-8aa2cb289ad0@mailbox.org>
 <f84a6583-50cc-416b-9abd-2b5795aa74ac@aklaver.com>
 <aa9df674-0f08-458b-8f09-08cfb57b915c@mailbox.org>
 <CAKFQuwZf+1frb+82G2-2tD84GXEpuCG_WZaiAU46=L2PDa9gYw@mail.gmail.com>
 <9a7ca237-7696-40e3-9ae6-12bd98c1b86c@mailbox.org>
Content-Language: en-US
From: Adrian Klaver <adrian.klaver@aklaver.com>
In-Reply-To: <9a7ca237-7696-40e3-9ae6-12bd98c1b86c@mailbox.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://www.postgresql.org/message-id/5dc9dd9e-a3c9-45a1-8497-7e304812eb8c%40aklaver.com>
Precedence: bulk

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@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?
> 

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.

-- 
Adrian Klaver
adrian.klaver@aklaver.com