Обсуждение: pg_dump doesn't save altered column information for inherited columns

Hello,

I noticed that when pg_dump saves SQL code for a table with inheritance, it=
 does not save any information about inherited columns. This is fine when i=
nherited columns do not undergo any modification, but when they do, that in=
formation is lost.

Example:

create table parent (id integer not null);

create table child (value integer) inherits (parent);

alter table child alter column id drop not null;

insert into child values (null, 1);

Here is the code of the child table as generated by pg_dump:

CREATE TABLE child (
    value integer
)
INHERITS (parent);

When the table is recreated using this code, the id column has the NOT NULL=
 restriction, which was not present in the original.

I don't think this is right. Either inherited columns should be immune to c=
hanges, or else pg_dump should reflect those changes in its SQL code.

Dmitry

Dmitry Epstein | Developer
Allied Testing
T + 7 495 544 48 69 Ext 417
M + 7 926 215 73 36

www.alliedtesting.com<http://www.alliedtesting.com/>
We Deliver Quality.

<depstein@alliedtesting.com> writes:
> I noticed that when pg_dump saves SQL code for a table with inheritance, it does not save any information about
inheritedcolumns. This is fine when inherited columns do not undergo any modification, but when they do, that
informationis lost. 

> Example:

> create table parent (id integer not null);

> create table child (value integer) inherits (parent);

> alter table child alter column id drop not null;

Actually, the bug here is that ALTER TABLE lets you do that.  Dropping
an inherited constraint should be disallowed, and is disallowed for the
case of CHECK constraints.  We haven't gotten around to enhancing the
NOT NULL infrastructure to detect that, but it's on the TODO list.
In the meantime, there's no point in modifying pg_dump to worry about
such cases.

            regards, tom lane