Excerpts from Greg Smith's message of vie dic 16 15:02:20 -0300 2011: > On 12/04/2011 02:22 AM, Nikhil Sontakke wrote: > > > > Is it okay to modify an existing constraint to mark it as "only", even > > if it was originally inheritable? This is not clear to me. Maybe the > > safest course of action is to raise an error. Or maybe I'm misreading > > what it does (because I haven't compiled it yet). > > > > > > Hmmm, good question. IIRC, the patch will pass is_only as true only if > > it going to be a locally defined, non-inheritable constraint. So I > > went by the logic that since it was ok to merge and mark a constraint > > as locally defined, it should be ok to mark it non-inheritable from > > this moment on with that new local definition?
I think I misread what that was trying to do. I thought it would turn on the "is only" bit on a constraint that a child had inherited from a previous parent, but that was obviously wrong now that I think about it again. > With this open question, this looks like it's back in Alvaro's hands > again to me. This one started the CF as "Ready for Committer" and seems > stalled there for now. I'm not going to touch its status, just pointing > this fact out. Yeah. Nikhil, Alex, this is the merged patch. Have a look that it still works for you (particularly the pg_dump bits) and I'll commit it. I adjusted the regression test a bit too. Thanks. -- Álvaro Herrera <alvhe...@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
non_inh_check_v4.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers