Re: Bug of ALTER TABLE DROP CONSTRAINT
От | Bruce Momjian |
---|---|
Тема | Re: Bug of ALTER TABLE DROP CONSTRAINT |
Дата | |
Msg-id | 200904071445.n37EjD015354@momjian.us обсуждение исходный текст |
Ответ на | Re: Bug of ALTER TABLE DROP CONSTRAINT (Nikhil Sontakke <nikhil.sontakke@enterprisedb.com>) |
Ответы |
Re: Bug of ALTER TABLE DROP CONSTRAINT
|
Список | 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 по дате отправления: