Re: Review of patch renaming constraints

On fre, 2012-01-20 at 11:32 +0530, Nikhil Sontakke wrote:
> Agreed. And right now primary key constraints are not marked as only
> making them available for inheritance in the future. Or you prefer it
> otherwise?
> 
> Anyways, fail to see the direct connection between this and renaming.
> Might have to look at this patch for that.

It checks conisonly to determine whether it needs to rename the
constraint in child tables as well.  Since a primary has conisonly =
false, it goes to the child tables, but the constraint it not there.

In the past, we have treated this merely as an implementation artifact:
check constraints are inherited, primary key constraints are not.  Now
we can choose for check constraints, with inherited being the default.
Having inheritable primary key constraints is a possible future feature.
So we need to think a littler harder now how to work that into the
existing logic.  This also ties in with the other thread about having
this in CREATE TABLE syntax.