Re: ALTER TABLE...ALTER COLUMN vs inheritance

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bernd Helmle <mailings(at)oopsware(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: ALTER TABLE...ALTER COLUMN vs inheritance
Date: 2009-11-04 14:57:27
Message-ID: 15656.1257346647@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bernd Helmle <mailings(at)oopsware(dot)de> writes:
> Consider the following workflow:

> CREATE TABLE foo(id integer NOT NULL, val text NOT NULL);
> CREATE TABLE foo2(another_id integer NOT NULL) INHERITS(foo);

> Now someone decides he doesn't want the NOT NULL constraint on the
> inherited column "val" anymore:

> ALTER TABLE foo2 ALTER COLUMN val DROP NOT NULL;

Yeah, this is a known issue. The ALTER should be rejected, but it is
not, because we don't have enough infrastructure to notice that the
constraint is inherited and logically can't be dropped. I think the
consensus was that the way to fix this (along with some other problems)
is to start representing NOT NULL constraints in pg_constraint, turning
attnotnull into just a bit of denormalization for performance.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2009-11-04 15:26:01 actualised funcs typmod patch
Previous Message Robert Haas 2009-11-04 14:44:10 Re: PL/Python array support