Review of patch renaming constraints

Поиск
Список
Период
Сортировка
Искать

Review of patch renaming constraints

От:
Joshua Berkus <josh@agliodbs.com>
Дата:

Re: Review of patch renaming constraints

От:
Peter Eisentraut <peter_e@gmx.net>
Дата:

Re: Review of patch renaming constraints

От:
Peter Eisentraut <peter_e@gmx.net>
Дата:

Re: Review of patch renaming constraints

От:
Peter Eisentraut <peter_e@gmx.net>
Дата:

Re: Review of patch renaming constraints

От:
Peter Eisentraut <peter_e@gmx.net>
Дата:
On tor, 2012-01-12 at 22:43 -0600, Joshua Berkus wrote:
> Most normal uses of alter table ... rename constraint ... worked
> normally.  However, the patch does not deal correctly with constraints
> which are not inherited, such as primary key constraints:

New patch which works around that issue.

Re: Review of patch renaming constraints

От:
Dimitri Fontaine <dimitri@2ndQuadrant.fr>
Дата:

Re: Review of patch renaming constraints

От:
Nikhil Sontakke <nikkhils@gmail.com>
Дата:
 
> Make check passed.  Patch has tests for rename constraint.
>
> Most normal uses of alter table ... rename constraint ... worked normally.  However, the patch does not deal correctly with constraints which are not inherited, such as primary key constraints:

That appears to be because creating a primary key constraint does not
set pg_constraint.conisonly correctly.  This was introduced recently
with noninherited check constraints.


Umm, conisonly is set as false from primary key entries in pg_constraint. And primary keys are anyways not inherited. So why is the conisonly field interfering in rename? Seems quite orthogonal to me.

Regards,
Nikhils

Re: Review of patch renaming constraints

От:
Nikhil Sontakke <nikkhils@gmail.com>
Дата:
 
> 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.

Regards,
Nikhils
FAQ