Re: Bug of ALTER TABLE DROP CONSTRAINT

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > Nikhil Sontakke wrote:
> >> Warrants an entry in the TODO items list:
> >>
> >> * make NOT NULL constraints have pg_constraint entries, just like CHECK
> >> constraints
>
> > This is now a TODO item (I just updated the description):
>
> > Store the constraint names of NOT NULL constraints
>
> I was intending to do that yesterday, but lost interest after
> discovering how many duplicate, obsolete, and/or mutually contradictory
> TODO entries there are related to constraints. That needs to be cleaned
> up and consolidated sometime.
>
> Also, what is wrong with the precise statement of the TODO item that
> Nikhil gave? The one you gave would encourage someone to waste time on
> a 100% wrong implementation (like adding a constraint name column to
> pg_attribute).

I felt the original wording would be unclear in explaining the problem
behavior; you are right the original wording was clearer for correcting
the problem. This updated wording works for both audiences, I think:

Move NOT NULL constraint information to pg_constraint

Currently NOT NULL constraints are stored in pg_attribute without
any designation of their origins, e.g. primary keys. One manifest
problem is that dropping a PRIMARY KEY constraint does not remove the
NOT NULL constraint designation.

*
http://archives.postgresql.org/message-id/19768.1238680878@sss.pgh.pa.us

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +