Re: BUG #3973: pg_dump using inherited tables do not always restore - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #3973: pg_dump using inherited tables do not always restore
Date
Msg-id 28159.1203548106@sss.pgh.pa.us
Whole thread Raw
In response to BUG #3973: pg_dump using inherited tables do not always restore  ("Alex Hunsaker" <badalex@gmail.com>)
Responses Re: BUG #3973: pg_dump using inherited tables do not always restore  ("Alex Hunsaker" <badalex@gmail.com>)
List pgsql-bugs
"Alex Hunsaker" <badalex@gmail.com> writes:
> create table junk (val integer not null, val2 integer);
> create table junk_child () inherits (junk_1);
> alter table junk_child alter column val drop not null;
> insert into junk_child (val2) values (1);

> pg_dump -t junk -t junk_child

> pg_restore/psql will fail because junk_child.val now has a not null
> constraint

Actually the bug is that ALTER TABLE allows you to do that.  It should
not be possible to drop an inherited constraint, but right now there's
not enough information in the system catalogs to detect the situation.
Fixing this has been on the TODO list for awhile:

    o %Prevent child tables from altering or dropping constraints
          like CHECK that were inherited from the parent table

            regards, tom lane

pgsql-bugs by date:

Previous
From: "Alex Hunsaker"
Date:
Subject: BUG #3973: pg_dump using inherited tables do not always restore
Next
From: "Markus Bertheau"
Date:
Subject: Incomplete docs for restore_command for hot standby