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
> 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
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|