Tom Lane <tgl@sss.pgh.pa.us> writes:
> Greg Stark <gsstark@mit.edu> writes:
> > Tom Lane <tgl@sss.pgh.pa.us> writes:
> >> 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.
>
> > 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.
>
> So? They'll get re-merged with the parent column during CREATE TABLE
> anyway.
But merged columns that are defined locally still appear in the position they
were defined locally. Not with the other inherited columns.
It's not going to matter to partitioned table users who are dropping the only
parent since that will just make *all* the columns into local columns. And
it's not going to matter to someone who drops all parents and then replaces
them in the same order.
But it will matter to the same people to whom the reordered inhseqno matters.
If you drop a parent and then readd it then that parent will both go to the
end of the list of parents which make any of multiple-inherited columns from
that parent go to the end of the list as well as mark any singly-inherited
columns from that parent as local which push them to the start of the list.
Note that if you don't re-add the parents you'll be left with a column order
that intermixes inherited and locally defined columns which *can't* be created
in postgres no matter what sequence of commands pg_dump dumps.
Basically I think if you're doing multiple inheritance and start using
add/drop inherits your column order is going to turn into chop suey quickly. I
think the only way to fix that would be to basically erase the whole
local/inherited distinction and let pg_dump specify the precise order of all
the columns.
--
greg