Skip site navigation (1) Skip section navigation (2)

Re: BUG #3973: pg_dump using inherited tables do not always restore

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: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugspgsql-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

In response to


pgsql-bugs by date

Next:From: Markus BertheauDate: 2008-02-21 02:01:39
Subject: Incomplete docs for restore_command for hot standby
Previous:From: Alex HunsakerDate: 2008-02-20 21:03:29
Subject: BUG #3973: pg_dump using inherited tables do not always restore

pgsql-patches by date

Next:From: Stephen DaviesDate: 2008-02-21 00:19:48
Subject: ts_headline
Previous:From: Jan WieckDate: 2008-02-20 21:14:58
Subject: Re: Proposed patch to change TOAST compression strategy

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group