On 12/5/24 14:32, PopeRigby wrote:
On 12/1/24 13:55, Tom Lane wrote:
Adrian Klaver <adrian.klaver@xxxxxxxxxxx> 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
So, is there anything I can do to fix this particular backup? I'm kind
of stuck here. There's also the issue with it for some reason failing to
connect to the lldap database after it literally just created it. Some
weird things going on.
In the pg_dumpall sql script did you change:
SELECT pg_catalog.set_config('search_path', '', false);
to
SELECT pg_catalog.set_config('search_path', 'public', false);
?
Show us the connection error you got for the lldap database.
--
Adrian Klaver
adrian.klaver@xxxxxxxxxxx
