| 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: | Whole Thread | Raw Message | 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 |