On 12/5/24 14:48, Adrian Klaver wrote:
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.
It actually looks like setting those all to have public fixed all the
errors, including the one with lldap. So, how can I get it to not put
public there automatically for next time?
