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
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 |