Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group