On 12/1/24 13:55, Tom Lane wrote: > 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
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.
Another alternative is to open the .sql file in Notepad++, then add "public." before all the unqualified "earth" and "ll_to_earth" references.
