From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Alex Hunsaker" <badalex(at)gmail(dot)com> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #3973: pg_dump using inherited tables do not always restore |
Date: | 2008-02-20 22:55:06 |
Message-ID: | 28159.1203548106@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-patches |
"Alex Hunsaker" <badalex(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Markus Bertheau | 2008-02-21 02:01:39 | Incomplete docs for restore_command for hot standby |
Previous Message | Alex Hunsaker | 2008-02-20 21:03:29 | BUG #3973: pg_dump using inherited tables do not always restore |
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Davies | 2008-02-21 00:19:48 | ts_headline |
Previous Message | Jan Wieck | 2008-02-20 21:14:58 | Re: Proposed patch to change TOAST compression strategy |