Re: Errors when restoring backup created by pg_dumpall - Mailing list pgsql-general

From Tom Lane
Subject Re: Errors when restoring backup created by pg_dumpall
Date
Msg-id 1475512.1733090108@sss.pgh.pa.us
Whole thread Raw
In response to Re: Errors when restoring backup created by pg_dumpall  (Adrian Klaver <adrian.klaver@aklaver.com>)
Responses Re: Errors when restoring backup created by pg_dumpall
List pgsql-general
Adrian Klaver <adrian.klaver@aklaver.com> writes:
> On 12/1/24 13:14, Tom Lane wrote:
>> It would be useful to know what is the command at line 4102
>> of all.sql.

> It is here:

> https://gist.github.com/poperigby/fcb59eb6c22c6051800e06a0ec482b49

> CREATE TABLE public.geodata_places (
>      id integer NOT NULL,
>      name character varying(200) NOT NULL,
>      longitude double precision NOT NULL,
>      latitude double precision NOT NULL,
>      "countryCode" character(2) NOT NULL,
>      "admin1Code" character varying(20),
>      "admin2Code" character varying(80),
>      "modificationDate" date NOT NULL,
>      "earthCoord" public.earth GENERATED ALWAYS AS 
> (public.ll_to_earth(latitude, longitude)) STORED,
>      "admin1Name" character varying,
>      "admin2Name" character varying,
>      "alternateNames" character varying
> );

Ah!  Then the failure occurs because we do a planning pass on the
GENERATED expression (I don't remember exactly why that's needed
during CREATE TABLE).  So maybe messing with the dump script's
search_path setting *would* be enough to get you past that.

Having said that, the CREATE should have been seeing the new-style
definition of ll_to_earth() if the 1.2 version of earthdistance
was correctly installed.

            regards, tom lane



pgsql-general by date:

Previous
From: Adrian Klaver
Date:
Subject: Re: Errors when restoring backup created by pg_dumpall
Next
From: Arbol One
Date:
Subject: Help with syntax error