Re: [HACKERS] Review of patch renaming constraints

2012-03-09 Thread Dimitri Fontaine
Hi, Peter Eisentraut writes: > 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

Re: [HACKERS] Review of patch renaming constraints

2012-02-01 Thread Peter Eisentraut
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: [HACKERS] Review of patch renaming constraints

2012-01-21 Thread Peter Eisentraut
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 ha

Re: [HACKERS] Review of patch renaming constraints

2012-01-19 Thread Nikhil Sontakke
> > 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 t

Re: [HACKERS] Review of patch renaming constraints

2012-01-19 Thread Peter Eisentraut
On fre, 2012-01-20 at 09:08 +0530, Nikhil Sontakke wrote: > > 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. In the past, each kind of co

Re: [HACKERS] Review of patch renaming constraints

2012-01-19 Thread Nikhil Sontakke
> > 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

Re: [HACKERS] Review of patch renaming constraints

2012-01-19 Thread Peter Eisentraut
On tor, 2012-01-12 at 22:43 -0600, Joshua Berkus wrote: > Compiling on Ubuntu 10.04 LTS AMD64 on a GoGrid virtual machine from > 2012-01-12 git checkout. > > Patch applied fine. > > Docs are present, build, look good and are clear. > > Changes to gram.y required Bison 2.5 to compile. Are we re

[HACKERS] Review of patch renaming constraints

2012-01-12 Thread Joshua Berkus
Compiling on Ubuntu 10.04 LTS AMD64 on a GoGrid virtual machine from 2012-01-12 git checkout. Patch applied fine. Docs are present, build, look good and are clear. Changes to gram.y required Bison 2.5 to compile. Are we requiring Bison 2.5 now? There's no configure check for it, so it took