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.

In response to

• Re: Review of patch renaming constraints at 2012-01-20 06:02:25 from Nikhil Sontakke

pgsql-hackers by date

Next:	From: Jim Nasby	Date: 2012-01-21 22:29:58
	Subject: Re: Removing freelist (was Re: Should I implement DROP INDEX CONCURRENTLY?)
Previous:	From: Jeff Janes	Date: 2012-01-21 20:51:58
	Subject: Re: [v9.2] Fix Leaky View Problem