From: Tom Lane <tgl@sss.pgh.pa.us>
To: Adrian Klaver <adrian.klaver@aklaver.com>
cc: PopeRigby <poperigby@mailbox.org>,
        "David G. Johnston" <david.g.johnston@gmail.com>,
        "pgsql-general@postgresql.org" <pgsql-general@postgresql.org>
Subject: Re: Errors when restoring backup created by pg_dumpall
In-reply-to: <92405f98-7f0c-4442-8252-697352daefc1@aklaver.com>
References: <6a6439f1-8039-44e2-8fb9-59028f7f2014@mailbox.org> <cba48d2c-0987-4233-a86f-2e693677efd3@aklaver.com> <9c5ba566-27b8-4e8c-bf7d-2dc561509991@mailbox.org> <CAKFQuwaB5GuUNuyiUbS0ah-LYXepHLPnOHrP7g8RMz8ywOm3zQ@mail.gmail.com> <ff94f628-27af-4c3a-9590-cba38bb5d2d1@mailbox.org> <CAKFQuwYQUequkYVS8SLgC1L0TOdWNK=xVyxnPD9RPPwfvYRFSQ@mail.gmail.com> <41791b6d-aaf5-4fed-9cc3-e89bc49e8637@mailbox.org> <CAKFQuwbe4TSU_LxsrGxgcv4DfQq2x-UNoyKx-ABy36PhvbGCdg@mail.gmail.com> <1257068.1733025493@sss.pgh.pa.us> <06425038-e012-4bac-aec1-d9541436f893@mailbox.org> <92405f98-7f0c-4442-8252-697352daefc1@aklaver.com>
Comments: In-reply-to Adrian Klaver <adrian.klaver@aklaver.com>
	message dated "Sun, 01 Dec 2024 13:08:28 -0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <1470485.1733087658.1@sss.pgh.pa.us>
Content-Transfer-Encoding: 8bit
Date: Sun, 01 Dec 2024 16:14:18 -0500
Message-ID: <1470486.1733087658@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/1470486.1733087658%40sss.pgh.pa.us>
Precedence: bulk

Adrian Klaver <adrian.klaver@aklaver.com> writes:
> On 12/1/24 12:05, PopeRigby wrote:
>> I'm still getting this error:
>> 
>> psql:all.sql:4102: ERROR:  type "earth" does not exist
>> LINE 1: ...ians($1))*sin(radians($2))),earth()*sin(radians($1)))::earth

> The issue is still this:
> SELECT pg_catalog.set_config('search_path', '', false);
> in the pg_dumpall output.

We've done that for some time, though.

> As was suggested before change the above to:
> SELECT pg_catalog.set_config('search_path', 'public', false);
> in the pg_dumpall output file.

I'm betting that won't help.  The new-in-17 behavior is that
maintenance commands such as CREATE INDEX internally force
a "safe" search_path, regardless of the prevailing setting.

It would be useful to know what is the command at line 4102
of all.sql.

			regards, tom lane