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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #3973: pg_dump using inherited tables do not always restore
Дата
Msg-id 28159.1203548106@sss.pgh.pa.us
обсуждение исходный текст
Ответ на BUG #3973: pg_dump using inherited tables do not always restore  ("Alex Hunsaker" <badalex@gmail.com>)
Ответы Re: BUG #3973: pg_dump using inherited tables do not always restore  ("Alex Hunsaker" <badalex@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: "Alex Hunsaker"
Дата:
Сообщение: BUG #3973: pg_dump using inherited tables do not always restore
Следующее
От: "Markus Bertheau"
Дата:
Сообщение: Incomplete docs for restore_command for hot standby