Re: Errors when restoring backup created by pg_dumpall

On 11/30/24 19:26, PopeRigby wrote:
> On 11/30/24 18:41, David G. Johnston wrote:
>> On Saturday, November 30, 2024, PopeRigby <poperigby@mailbox.org> wrote:
>>
>>     On 11/30/24 17:27, David G. Johnston wrote:
>>>     On Saturday, November 30, 2024, PopeRigby <poperigby@mailbox.org>
>>>     wrote:
>>>
>>>         On 11/29/24 17:47, Adrian Klaver wrote:
>>>
>>>             On 11/29/24 17:34, PopeRigby wrote:
>>>
>>>             psql:all.sql:4104: ERROR:  type "earth" does not exist
>>>             LINE 1:
>>>             ...ians($1))*sin(radians($2))),earth()*sin(radians($1)))::earth
>>>
>>>             QUERY:  SELECT
>>>
cube(cube(cube(earth()*cos(radians($1))*cos(radians($2))),earth()*cos(radians($1))*sin(radians($2))),earth()*sin(radians($1)))::earth
>>>             CONTEXT:  SQL function "ll_to_earth" during inlining
>>>              The earthdistance module is even getting added between
>>>             the table with the earth type is added, so shouldn't
>>>             there be no problem?
>>>
>>>
>>>     The fact that “earth” is not schema qualified leads me to suspect
>>>     you are getting bit by safe search_path environment rules.
>>>
>>>     David J.
>>
>>     Ah. How can I fix that?
>>
>> Since you are past the point of fixing the source to produce valid 
>> dumps…that leaves finding the places in the text the lack the schema 
>> qualification and manually adding them in.
>>
>> David J.
>>
> Oh boy. How can I prevent this from happening again?
> 

In future schema qualify all references.

For now in the dump file you could search for

SELECT pg_catalog.set_config('search_path', '', false);

and set to

SELECT pg_catalog.set_config('search_path', 'public', false);





-- 
Adrian Klaver
adrian.klaver@aklaver.com