I bumped into a sequence of commands that breaks pg_dump & restore:
------------
create table at_tab (a int, b int);
create table at_tab_child (a int, b int);
alter table at_tab_child inherit at_tab;
-- You can use the child's rowtype in the DEFAULT without a cast.
CREATE FUNCTION func_with_default(
arg at_tab DEFAULT ('(1, 2)'::at_tab_child)
) RETURNS integer LANGUAGE plpgsql as $$
begin
return arg.b;
end;
$$;
-- We allow detaching the child from the parent, despite the DEFAULT
-- expression. That is a not good, because if you try to recreate the
-- function, it's not accepted. I.e. pg_dump & restore is broken
alter table at_tab_child no inherit at_tab;
------------
The function still works after that. But if you run pg_dump (or do \ef
or something), the CREATE FUNCTION is deparsed as above, and when you
try to restore it you get an error:
ERROR: argument of DEFAULT must be type at_tab, not type at_tab_child
LINE 1: ...CTION public.func_with_default(arg at_tab DEFAULT '(1,2)'::a...
You get the same effect with ATTACH/DETACH PARTITION instead of
INHERIT/NO INHERIT.
- Heikki
