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(at)mailbox(dot)org> wrote:
>>
>> On 11/30/24 17:27, David G. Johnston wrote:
>>> On Saturday, November 30, 2024, PopeRigby <poperigby(at)mailbox(dot)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(dot)klaver(at)aklaver(dot)com