On Sat, Jun 25, 2011 at 2:15 AM, Dean Rasheed <dean.a.rasheed@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
