Re: BUG #5064: not-null constraints is not inherited

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Tomonari Katsumata" <katsumata(dot)tomonari(at)oss(dot)ntt(dot)co(dot)jp>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #5064: not-null constraints is not inherited
Date: 2009-09-18 17:15:14
Message-ID: 3341.1253294114@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

"Tomonari Katsumata" <katsumata(dot)tomonari(at)oss(dot)ntt(dot)co(dot)jp> writes:
> postgres=# CREATE TABLE parent (id integer);
> postgres=# CREATE TABLE child () inherits (parent);
> postgres=# ALTER TABLE parent ADD PRIMARY KEY (id);

> child table does not have a "not null" constraints.
> I think it's not desirable behavier.

The code says:

* XXX: Shouldn't the ALTER TABLE .. SET NOT NULL cascade to child
* tables? Currently, since the PRIMARY KEY itself doesn't cascade,
* we don't cascade the notnull constraint(s) either; but this is
* pretty debatable.

Given that we've tightened things up to insist that child tables have
all the check constraints that the parent does, it seems like it might
be desirable to make the same rule for NOT NULL constraints. However,
while changing DefineIndex for this would be a one-liner change, there
are a lot of other implications of such a rule. This would have to
be rejected:
alter table only parent alter id set not null;
which again isn't a big deal. What is a big deal is that we'd also
have to forbid ALTER DROP NOT NULL on the child. For that, we'd need
to track whether NOT NULL constraints were inherited or not. There
is already a TODO item about that. I've added this thread to the
TODO entry.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Dimitri Fontaine 2009-09-18 19:44:51 Re: BUG #5062: 8.4.1 compile fails on debian can't find libdl
Previous Message Matt Taylor 2009-09-18 15:46:56 Re: BUG #5063: MS Access crashes by quiting after linking tables with PostgreSQL