Simon Riggs <simon@2ndquadrant.com> writes:
> Based on the test case Tom shows, I think we need to enforce that ADD
> INHERITS will barf if the columns are not in exactly the order they
> would have been in if we add done a CREATE ... INHERITS followed by a
> DROP INHERITS.
This seems overly strong; if we enforced that policy consistently, then
it would for example be illegal to ADD COLUMN to a parent. Consider
create table p(f1 int);create table c(f2 int) inherits (p);alter table p add column f3 int;
The column order in c will now be f1,f2,f3. However, after a dump and
reload it'll be f1,f3,f2, because f3 will already be an inherited column
when c is created. This is pretty much unavoidable and we've taken care
of the various loose ends needed to make it work safely.
What I'm saying is just that we should avoid *unnecessary* changes of
column order, and in particular that means taking at least a little care
to try to select a reasonable inhseqno during ADD INHERITS.
If you think the "first unused" policy wouldn't take care of enough
cases, one idea is to try to look at the columns that will be inherited
from the new parent, and to see if we can deduce a suitable inhseqno
based on those columns' positions. I suspect this will be a pretty ugly
heuristic though ...
regards, tom lane
