Re: Bug of ALTER TABLE DROP CONSTRAINT

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Nikhil Sontakke <nikhil(dot)sontakke(at)enterprisedb(dot)com>, Jacky Leng <lengjianquan(at)163(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Bug of ALTER TABLE DROP CONSTRAINT
Date: 2009-04-02 14:01:18
Message-ID: 19768.1238680878@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Actually it's more complicated than that. You'd need to remember
> whether or not the NOT NULL was added when the primary key was added,
> or whether it was there before, and only drop it if it wasn't there
> before.

We've discussed before the idea that NOT NULL constraints should be
explicitly represented in pg_constraint, just like general CHECK
constraints (this would allow them to be named, have sane inheritance
behavior, etc). If we had that, then pg_attribute.attnotnull could
indicate the OR of "there is a NOT NULL on this column" and "there is
a pkey constraint on this column", and you'd just have to recompute it
properly after dropping either kind of constraint.

Not happening for 8.4, but maybe someday someone will get around to it.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hitoshi Harada 2009-04-02 14:07:04 A trivial doc patch for pgstattuple
Previous Message Nikhil Sontakke 2009-04-02 13:17:48 Re: Bug of ALTER TABLE DROP CONSTRAINT