Greg Stark wrote:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>
>
>> Greg Stark <gsstark@mit.edu> writes:
>>
>>> It's not a precise noop in database internal data structures, but I don't see
>>> any user-visible effects switching around seqnos would have. But maybe there's
>>> something I don't know about?
>>>
>> It'll affect the order in which pg_dump lists the parents, which will
>> affect the order in which the columns are created on dump and reload.
>> (Or at least it ought to ... right offhand I don't see anything in the
>> pg_dump source code that ensures the original order is preserved. This
>> may be a pg_dump bug.)
>>
>
> Hm, if column order is important for table with multiple parents then you have
> other problems already. The attislocal->1 mutation will cause any
> singly-inherited columns to go to the head of the list. If you dropped any
> table but the first parent then it isn't going to matter if it's in the right
> place in the inheritance list or not.
>
> If you really want to preserve column order then it might be necessary to
> invent some syntax that indicates a column should be created with
> attislocal=f. Then pg_dump can dump a complete list of columns including
> inherited columns and CREATE TABLE can use that order merging in inherited
> definitions without changing the order.
>
> But it would be a nonstandard extension :(
>
>
>
hmm, I take it we will just select by name in some canonical order
(presumably the parent's order)?
ISTR discussion at one time of implementing logical vs. physical
ordering ... would that have any relevance here?
cheers
andrew
