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. And here I was thinking that this was just a quick job to enable NOT VALID constraints ... -- Álvaro Herrera <alvhe...@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
