Greg Stark wrote:
Tom Lane <[EMAIL PROTECTED]> writes:
Greg Stark <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
