Re: Bug of ALTER TABLE DROP CONSTRAINT - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Bug of ALTER TABLE DROP CONSTRAINT
Date
Msg-id 200904071445.n37EjD015354@momjian.us
Whole thread Raw
In response to Re: Bug of ALTER TABLE DROP CONSTRAINT  (Nikhil Sontakke <nikhil.sontakke@enterprisedb.com>)
Responses Re: Bug of ALTER TABLE DROP CONSTRAINT  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Nikhil Sontakke wrote:
> Hi,
> 
> 
> > 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.
> >
> 
> 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    Currently NOT NULL constraints are stored in pg_attribute
withoutanydesignation of their origins, e.g. primary keys. One manifestproblem is that dropping a PRIMARY KEY
constraintdoes not remove theNOT NULL constraint designation.        *
http://archives.postgresql.org/message-id/19768.1238680878@sss.pgh.pa.us
 

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Path separator
Next
From: Tom Lane
Date:
Subject: Re: Bug of ALTER TABLE DROP CONSTRAINT