On Thu, Dec 5, 2024 at 5:32 PM PopeRigby <poperi...@mailbox.org> wrote:
> On 12/1/24 13:55, Tom Lane wrote: > > Adrian Klaver <adrian.kla...@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. -- Death to <Redacted>, and butter sauce. Don't boil me, I'm still alive. <Redacted> lobster!
