Re: Review of patch renaming constraints

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Nikhil Sontakke <nikkhils(at)gmail(dot)com>
Cc: Joshua Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Review of patch renaming constraints
Date: 2012-01-21 22:13:55
Message-ID: 1327184035.4482.15.camel@vanquo.pezone.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Browse pgsql-hackers by date

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