Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tHabz-008ctB-Az for pgsql-general@arkaria.postgresql.org; Sun, 01 Dec 2024 03:27:08 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tHabv-0049bX-Ml for pgsql-general@arkaria.postgresql.org; Sun, 01 Dec 2024 03:27:04 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tHabv-0049bO-9u for pgsql-general@lists.postgresql.org; Sun, 01 Dec 2024 03:27:04 +0000 Received: from mout-p-102.mailbox.org ([2001:67c:2050:0:465::102]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tHabr-000Pnm-KF for pgsql-general@postgresql.org; Sun, 01 Dec 2024 03:27:02 +0000 Received: from smtp202.mailbox.org (smtp202.mailbox.org [10.196.197.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-102.mailbox.org (Postfix) with ESMTPS id 4Y1C5B598Jz9smJ; Sun, 1 Dec 2024 04:26:54 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailbox.org; s=mail20150812; t=1733023614; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=dMfGJIiTTJGyHiEEUWZOpuhFGm3KIhhHx7MwdYy9+kA=; b=Cc+NoB9Yw664bkjKg5yeLHApVP0KT4XKNFhpUUMLNgnZC7KhQk+cKgakguQxRbdbzhOdZF bMu5x8IgmP4HpipTNFWuCGygE6yBKpR+aHqEhbLYj6O/O85E28HUWIahucNtzbU4OziDGW jT4da1nKLMW7h251fWwHjCHaowuVsIbuHXFSN6ThznZ3AnxPz2Xr9a+6KJoOvFrHFTyGEh hc0xbjj2mZlS7FCdkL9WUVQ+XLPalyAtiDSrR0SXVejue+V2Cejk5X0isK0NQ+MINUpF63 bvqSMwcnUzsJESgOq17PwH9ArTjuY7CDTAdpW0SkUeElR/6TUccTfZVeVLNIQg== Content-Type: multipart/alternative; boundary="------------NxiN10TDs6vcFFUs76p22K1r" Message-ID: Date: Sat, 30 Nov 2024 19:26:51 -0800 MIME-Version: 1.0 Subject: Re: Errors when restoring backup created by pg_dumpall To: "David G. Johnston" Cc: Adrian Klaver , "pgsql-general@postgresql.org" References: <6a6439f1-8039-44e2-8fb9-59028f7f2014@mailbox.org> <9c5ba566-27b8-4e8c-bf7d-2dc561509991@mailbox.org> Content-Language: en-US From: PopeRigby In-Reply-To: X-MBO-RS-ID: f8ce3827ac534de468b X-MBO-RS-META: 74i5yfb9ksomzf8rb78s96uhxak48sxg List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------NxiN10TDs6vcFFUs76p22K1r Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 11/30/24 18:41, David G. Johnston wrote: > On Saturday, November 30, 2024, PopeRigby wrote: > > On 11/30/24 17:27, David G. Johnston wrote: >> On Saturday, November 30, 2024, PopeRigby >> 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? --------------NxiN10TDs6vcFFUs76p22K1r Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
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?

--------------NxiN10TDs6vcFFUs76p22K1r--