On Sat, Jun 25, 2011 at 2:15 AM, Dean Rasheed <dean.a.rash...@gmail.com> wrote: > Really? I would expect the reverse, namely that the not-nullness is > part of the PK constraint and dropping the PK *would* then start > allowing NULLs.
Hmm, OK. I had assumed we were only trying to fix the problem that parent and child inheritance tables could get out of step, but maybe you're right. If we go with that approach, then consider: CREATE TABLE foo (a int); CREATE TABLE bar () INHERITS (foo); Now if someone adds a primary key foo (a), what happens currently is that foo.a becomes NOT NULL, but bar.a still allows NULLs. Should that remain true (on the theory that a primary key constraint is not inherited) or become false (on the theory that parent and child tables should match)? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
