Re: Errors when restoring backup created by pg_dumpall
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Adrian Klaver <adrian.klaver@aklaver.com>
Cc: PopeRigby <poperigby@mailbox.org>,
"David G. Johnston" <david.g.johnston@gmail.com>,
"pgsql-general@postgresql.org" <pgsql-general@postgresql.org>
Date: 2024-12-01T21:55:08Z
Lists: 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
Commits
-
contrib/earthdistance: Use SQL-standard function bodies.
- 969bbd0fafc0 18.0 landed
- 3652de36e432 17.3 landed
- 31daa10facec 16.7 landed