Now that we have coninhcnt, conislocal etc... we can probably support
ONLY. But I agree with Robert it's probably a bit more than an
afternoon to crank out :-)
Heh, agreed :), I was just looking for some quick and early feedback. So what we need is basically a way to indicate that a particular constraint is non-inheritable forever (meaning - even for future children) and that should work?
Right now, it seems that the "ONLY" usage in the SQL only translates to a recurse or no-recurse operation. For the parent, a constraint is marked with conislocal set to true (coninhcount is 0) and for children, coninhcount is used to indicate inheritance of that constraint with conislocal being set to false.
What we need is to persist information of a particular constraint to be as specified - ONLY for this table. We could do that by adding a new column in pg_constraint like 'connoinh' or something, but I guess we would prefer not to get into the initdb business. Alternatively we could bring about the same by using a combination of conislocal and coninhcnt. For ONLY constraints, we will need to percolate this information down to the point where we define it in the code. We can then mark ONLY constraints to have conislocal set to TRUE and coninhcnt set to a special value (-1). So to summarize, what I am proposing is:
Introduce new column connoinh (boolean) in pg_constraint
OR in existing infrastructure:
Normal constraints: conislocal (true) coninhcnt (0) (inheritable like today)
Inherited constraints: conislocal (false) coninhcnt (n > 0)
ONLY constraints: conislocal (true) coninhcnt (-1) (not inheritable)
With this arrangment, pg_dump will be able to easily identify and spit out ONLY specifications for specific constraints and then they won't be blindly passed on to children table under these new semantics.
Thoughts? Anything missing? Please let me know.
Regards,
Nikhils
