I wrote: > I find it surprising that the committed patch does not touch > pg_dump. Is it really true that pg_dump dumps situations with > differing compression/storage settings accurately already?
It's worse than I thought. Run "make installcheck" with today's HEAD, then: $ pg_dump -Fc regression >r.dump $ createdb r2 $ pg_restore -d r2 r.dump pg_restore: error: could not execute query: ERROR: column "a" inherits conflicting storage methods HINT: To resolve the conflict, specify a storage method explicitly. Command was: CREATE TABLE public.stchild4 ( a text ) INHERITS (public.stparent1, public.stparent2); ALTER TABLE ONLY public.stchild4 ALTER COLUMN a SET STORAGE MAIN; pg_restore: error: could not execute query: ERROR: relation "public.stchild4" does not exist Command was: ALTER TABLE public.stchild4 OWNER TO postgres; pg_restore: error: could not execute query: ERROR: relation "public.stchild4" does not exist Command was: COPY public.stchild4 (a) FROM stdin; pg_restore: warning: errors ignored on restore: 3 What I'd intended to compare was the results of the query added to the regression tests: regression=# SELECT attrelid::regclass, attname, attstorage FROM pg_attribute WHERE (attrelid::regclass::name like 'stparent%' OR attrelid::regclass::name like 'stchild%') and attname = 'a' ORDER BY 1, 2; attrelid | attname | attstorage -----------+---------+------------ stparent1 | a | p stparent2 | a | x stchild1 | a | p stchild3 | a | m stchild4 | a | m stchild5 | a | x stchild6 | a | m (7 rows) r2=# SELECT attrelid::regclass, attname, attstorage FROM pg_attribute WHERE (attrelid::regclass::name like 'stparent%' OR attrelid::regclass::name like 'stchild%') and attname = 'a' ORDER BY 1, 2; attrelid | attname | attstorage -----------+---------+------------ stparent1 | a | p stchild1 | a | p stchild3 | a | m stparent2 | a | x stchild5 | a | p stchild6 | a | m (6 rows) So not only does stchild4 fail to restore altogether, but stchild5 ends with the wrong attstorage. This patch definitely needs more work. regards, tom lane