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 1tHauH-008eZI-8j for pgsql-general@arkaria.postgresql.org; Sun, 01 Dec 2024 03:46:01 +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 1tHauE-004RdK-Nd for pgsql-general@arkaria.postgresql.org; Sun, 01 Dec 2024 03:45:59 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tHauE-004RdC-8d for pgsql-general@lists.postgresql.org; Sun, 01 Dec 2024 03:45:59 +0000 Received: from mail-oa1-x35.google.com ([2001:4860:4864:20::35]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tHauC-000QAS-I4 for pgsql-general@postgresql.org; Sun, 01 Dec 2024 03:45:58 +0000 Received: by mail-oa1-x35.google.com with SMTP id 586e51a60fabf-29645a83b1bso1768181fac.1 for ; Sat, 30 Nov 2024 19:45:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733024756; x=1733629556; darn=postgresql.org; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=P66fVnLh3Npi1bNGoNvUNZllka7hrzO6h0cYAxovf4s=; b=j2goKVYSVJw9MZMs8c7YK62Cb9q/qJPHCeCnGjCZmluUNAxj8h76sE98Np9Vl0ODP7 2djTWzwN4gF0V93yHkkxU2QXpXsz5N9KGvTIWOWFSTlhlrCoK/nkBn5s7N6TzoVGalZ6 7ANt8rZETH1rq8ZfidWscM9BgXtD+p+/o2ioii2TpbjHxsUcmJMbwQrA+bsED91BP4b0 JsDYKony/rIjwxPAqMQwisRJdzUGw4xmj1CzagUpFaz3cRz9Rn8nu77Y5ini+J3pkQVW 2KO/qfvkdA8BaKKjqF0Pmq3It76iT2gaScKA5Oz+86mASbT0Y5XXR8peABA0Zg2IOR5x 8KDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733024756; x=1733629556; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=P66fVnLh3Npi1bNGoNvUNZllka7hrzO6h0cYAxovf4s=; b=RjQ/ayUt29psqJ06u4HXSbQXaNkXOOHoiJ3XgNNqpPXGRlb7HuT2q1wVR3/MrwUj5T b+XQ8Y1pb71gdtRlxXyIrZxJ71z+c/jw+8V6llUDU959P2Es/TvE1hWyLaasbnFJcu+3 I/1h5/JbAj9+bNi6X5Cvvc0/dDln2MRCno1SiNN7zrjJRt2UZ5rrcBjOqaA4LH4WB1G4 rvEKi574pEuDDjoGh3EHC+BG3iQ3WTMbDDctDGfoX85OpjHV9LolLjH1Lz+xG1tVKPia nX+3TsDhmiqtFzem63mLfmpUZKmopzUVbY2frJrUGZOxqgitEZw+F9R9tgywg6FsvgbV wqvw== X-Forwarded-Encrypted: i=1; AJvYcCVR9jukMzBzi5hhYO2VagUVCbZZzvw8CoDzDb1MLareKPCrKARRh+IWacIyYqEOo/1T6fW3/BbsP9vs2STf@postgresql.org X-Gm-Message-State: AOJu0YwhRl6hCATe9gavaWkd5DyFbETT0aStd6Y7MC+crka0h+8H7Eu7 WWo7LecyEIhsdv52Qd8kGCtsr/LO3t029RV7/bWBNrA4jrBmUgHo7fbqIDicFtZSlG6GEX0NMz0 YhA5S2xRPA+ieA6u1RSi/2cwmWKs= X-Gm-Gg: ASbGncsD0AbumTG4xxdTTptdavPUihbw31Dzg6Vzr4ELx/XZli6k5/wm/MmCnpEQwBD pv6rT/jUJ5fp6ej7pM49p2yLClUYts0s= X-Google-Smtp-Source: AGHT+IH50EYbQevUfrnPoxmCf7//6dqf/bXRIzP3metN/59R6WzkLp0FK/5jMB8ndA3SJqzIL0SsiMoZI2jfBpdasM8= X-Received: by 2002:a05:6870:b18:b0:29e:49b3:c527 with SMTP id 586e51a60fabf-29e49b3e819mr1548315fac.24.1733024755746; Sat, 30 Nov 2024 19:45:55 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a8a:516:0:b0:56c:c9af:3ee6 with HTTP; Sat, 30 Nov 2024 19:45:55 -0800 (PST) In-Reply-To: <41791b6d-aaf5-4fed-9cc3-e89bc49e8637@mailbox.org> References: <6a6439f1-8039-44e2-8fb9-59028f7f2014@mailbox.org> <9c5ba566-27b8-4e8c-bf7d-2dc561509991@mailbox.org> <41791b6d-aaf5-4fed-9cc3-e89bc49e8637@mailbox.org> From: "David G. Johnston" Date: Sat, 30 Nov 2024 20:45:55 -0700 Message-ID: Subject: Re: Errors when restoring backup created by pg_dumpall To: PopeRigby Cc: Adrian Klaver , "pgsql-general@postgresql.org" Content-Type: multipart/alternative; boundary="000000000000f40d8906282d44c2" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000f40d8906282d44c2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Saturday, November 30, 2024, PopeRigby wrote: > 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)))::eart= h >>>> >>>> QUERY: SELECT cube(cube(cube(earth()*cos(rad >>>> ians($1))*cos(radians($2))),earth()*cos(radians($1))*sin(rad >>>> ians($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 =E2=80=9Cearth=E2=80=9D is not schema qualified leads me t= o 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=E2=80=A6that leaves finding the places in the text the lack the sch= ema > qualification and manually adding them in. > > David J. > > Oh also, it's the schema is specified as public on this line: > https://gist.github.com/poperigby/fcb59eb6c22c6051800e06a0ec482b > 49#file-redacted_all-sql-L4111 > > Why is it not finding it? I queried public and earth was in there. > Ok, so the error is not emanating from your code but rather the body of the ll_to_earth function defined in the earthdistance extension. David J. --000000000000f40d8906282d44c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Saturday, November 30, 2024, PopeRigby <poperigby@mailbox.org> wrote:
=20 =20 =20
On 11/30/24 18:41, David G. Johnston wrote:
=20 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:=C2=A0 type "earth" does= not exist
LINE 1: ...ians($1))*sin(radians($2))),earth()*sin(rad= ians($1)))::earth

QUERY:=C2=A0 SELECT cube(cube(cube(earth()*cos(radians= ($1))*cos(radians($2))),earth()*cos(radians($1))*sin(radians($2))= ),earth()*sin(radians($1)))::earth
CONTEXT:=C2=A0 SQL function "ll_to_earth" during = inlining
=C2=A0The earthdistance module is even getting added betwee= n the table with the earth type is added, so shouldn't there be no problem?

The fact that =E2=80=9Cearth=E2=80=9D is not schema qualif= ied leads me to suspect you are getting bit by safe search_path environment rules.

David J.=C2=A0

Ah. How can I fix that?

Since you are past the point of fixing the source to produce valid dumps=E2=80=A6that leaves finding the places in the text the = lack the schema qualification and manually adding them in.

David J.

Oh also, it's the schema is specified as public on this line: https://gist.github.com/<= wbr>poperigby/fcb59eb6c22c6051800e06a0ec482b49#file-redacted_all-= sql-L4111

Why is it not finding it? I queried public and earth was in there.


Ok, so the error is not eman= ating from your code but rather the body of the ll_to_earth function define= d in the earthdistance extension.

David J.

--000000000000f40d8906282d44c2--