Re: table inheritance versus column compression and storage settings

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