On Wed, Jun 29, 2011 at 12:51 PM, Alvaro Herrera <alvhe...@commandprompt.com> wrote: > Excerpts from Robert Haas's message of lun jun 27 10:35:59 -0400 2011: >> On Mon, Jun 27, 2011 at 3:08 AM, Dean Rasheed <dean.a.rash...@gmail.com> >> wrote: > >> > I would summarise the consistency requirements as: >> > >> > 1). ADD CONSTRAINT should leave both parent and child tables in the >> > same state as they would have been if the constraint had been defined >> > at table creation time. >> > >> > 2). DROP CONSTRAINT should leave both parent and child tables in the >> > same state as if the constraint had never existed (completely >> > reversing the effects of ADD CONSTRAINT). >> > >> > I don't have a strong opinion as to whether or not the NOT NULL part >> > of a PK should be inherited, provided that it is consistent with the >> > above. >> > >> > I guess that if I were forced to choose, I would say that the NOT NULL >> > part of a PK should not be inherited, since I do think of it as part >> > of the PK, and PKs are not inherited. >> >> OK, I see your point, and I agree with you. > > Interesting. This whole thing requires quite a bit of rejiggering in > the initial transformation phase, I think, but yeah, I see the points > here and I will see to them. Does this mean that "NOT NULL PRIMARY KEY" > now behaves differently? I think it does , because if you drop the PK > then the field needs to continue being not null.
Yeah, I think an implicit not-null because you made it a primary key is now different from one that you write out. > And here I was thinking that this was just a quick job to enable NOT > VALID constraints ... Bwahaha. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
