Consider two tables foo(x int not null) and bar (x int). I fire the sql SQL1: alter table bar inherit foo;
Above sql causes "ERROR: column "x" in child table must be marked NOT NULL". This looks logically fine to me. So, I fire the sql SQL2: alter table bar alter column x set not null; Then I make bar a child of foo by firing SQL1. So now I have foo (x int not null), and bar (x int not null) inherits (foo). >From this state, the questions: ------------------------------------------- Q1. Why can I now successfully fire the following sql? SQL3: alter table bar alter column x drop not null; ------------------------------------------- Q2. Back to baseline, where we had not null constraints on both foo and bar. I can remove the not null constraints by SQL4: alter table foo alter column x drop not null; But now, I can successfully fire SQL5: alter table only foo alter column x set not null; Why is this so? ------------------------------------------- (The behavior seen in SQL3 and SQL5 seems contradictory to the behavior seen in SQL1. Shouldn't SQL1, SQL3 and SQL5 all share the same fate?) >From code perspective, the relevant methods are ATExecDropNotNull and ATExecSetNotNull. If the behavior seen above is incorrect/inconsistent, then following changes may have to be made: 1. ATExecDropNotNull: May have to see attinhcount of x, and deduce that not-null cannot be dropped. 2. ATExecSetNotNull: May have to always recurse; specifying ONLY during a SET NOT NULL may have to be treated as erroneous. Thanks, Srinath. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
