Horton

Re: Errors when restoring backup created by pg_dumpall

PopeRigby <poperigby@mailbox.org>

View thread View on postgr.es
From: PopeRigby <poperigby@mailbox.org>
To: "David G. Johnston" <david.g.johnston@gmail.com>
Cc: Adrian Klaver <adrian.klaver@aklaver.com>, "pgsql-general@postgresql.org" <pgsql-general@postgresql.org>
Date: 2024-12-01T03:26:51Z
Lists: pgsql-general 
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?

Commits

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