On Sun, Jul 5, 2009 at 5:10 PM, Greg Stark<gsstark(at)mit(dot)edu> wrote:
> On Sun, Jul 5, 2009 at 4:28 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> when i done dump->restore i
>>> have surprise,
>>> Column ordering was changed.
>> This is not a bug, it's the intended behavior.
> I thought that was a bug
Rereading the thread I'll also mention that your fix causes a
different problem. Every column becomes marked as having being created
in the child table which wasn't the case originally.
If you later drop one of those columns from the parent table it's
supposed to cascade to the children but it won't because now postgres
thinks the child had those columns defined independently.
In the current setup we can get either the shared vs local definition
above correct or we can get the ordering correct. Getting both correct
would require a rework of either the way inheritance works or the way
column ordering works.
In response to
pgsql-bugs by date
|Next:||From: Tom Lane||Date: 2009-07-05 16:18:39|
|Subject: Re: Diffrent column ordering after dump/restore tables with INHERITS |
|Previous:||From: Greg Stark||Date: 2009-07-05 16:10:36|
|Subject: Re: Diffrent column ordering after dump/restore tables with INHERITS|