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

Re: Review of patch renaming constraints

From: Nikhil Sontakke <nikkhils(at)gmail(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Joshua Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Review of patch renaming constraints
Date: 2012-01-20 06:02:25
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> > And primary keys are anyways not inherited. So why is the conisonly
> > field interfering in rename? Seems quite orthogonal to me.
> In the past, each kind of constraint was either always inherited or
> always not, implicitly.  Now, for check constraints we can choose what
> we want, and in the future, perhaps we will want to choose for primary
> keys as well.  So having conisonly is really a good step into that
> future, and we should use it uniformly.
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.


In response to


pgsql-hackers by date

Next:From: Greg SmithDate: 2012-01-20 07:47:15
Subject: Re: Patch review for logging hooks (CF 2012-01)
Previous:From: Peter EisentrautDate: 2012-01-20 05:09:24
Subject: Re: Review of patch renaming constraints

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