Re: Diffrent column ordering after dump/restore tables with INHERITS

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Oleg Serov <serovov(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: Diffrent column ordering after dump/restore tables with INHERITS
Date: 2009-07-05 16:15:12
Message-ID: 407d949e0907050915g5ba96ecdt24e831276d8b7213@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

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.

--
greg
http://mit.edu/~gsstark/resume.pdf

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2009-07-05 16:18:39 Re: Diffrent column ordering after dump/restore tables with INHERITS
Previous Message Greg Stark 2009-07-05 16:10:36 Re: Diffrent column ordering after dump/restore tables with INHERITS