On Mon, Dec 19, 2011 at 12:07 PM, Nikhil Sontakke <nikkh...@gmail.com> wrote: >> It seems hard to believe that ATExecDropConstraint() doesn't need any >> adjustment. > > Yeah, I think we could return early on for "only" type of constraints.
It's not just that. Suppose that C inherits from B which inherits from A. We add an "only" constraint to B and a non-"only" constraint to "A". Now, what happens in each of the following scenarios? 1. We drop the constraint from "B" without specifying ONLY. 2. We drop the constraint from "B" *with* ONLY. 3. We drop the constraint from "A" without specifying ONLY. 4. We drop the constraint from "A" *with* ONLY. Off the top of my head, I suspect that #1 should be an error; #2 should succeed, leaving only the inherited version of the constraint on B; #3 should remove the constraint from A and leave it on B but I'm not sure what should happen to C, and I have no clear vision of what #4 should do. As a followup question, if we do #2 followed by #4, or #4 followed by #2, do we end up with the same final state in both cases? Here's another scenario. B inherits from A. We a constraint to A using ONLY, and then drop it without ONLY. Does that work or fail? Also, what happens we add matching constraints to B and A, in each case using ONLY, and then remove the constraint from A without using ONLY? Does anything happen to B's constraint? Why or why not? Just to be clear, I like the feature. But I've done some work on this code before, and it is amazingly easy for to screw it up and end up with bugs... so I think lots of careful thought is in order. -- 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
