This is what I assumed the problem to be but I wasn't sure if there would be
more to it or not.
My question now is: Should the order in which columns are physically stored
matter?
Since the details of where to find the columns in the tuple data are stored
in pg_attribute, I'd think this is a place where the storage layer should be
free to store it as it likes. Consider as a performance enhancement
shuffling all the variable length columns to the end of the table. This
would save having to look at the size of all the variable length columns in
order to examine a fixed length column.
Obviously since I only have a brief understanding of how stuff works I'm
relying on you to point out whether this is even a valid suggestion.
-Michael
> Inheritance.
>
> CREATE TABLE parent (a, b, c);
>
> CREATE TABLE child (z) INHERITS (parent);
>
> ALTER TABLE parent ADD COLUMN (d);
>
> With the current implementation you now have column order a,b,c,d in the
> parent, and a,b,c,z,d in the child. This is seriously broken for a
> number of reasons, not least being that pg_dump can't realistically be
> expected to reproduce that state.