Re: ADD/DROP INHERITS - Mailing list pgsql-hackers

From Greg Stark
Subject Re: ADD/DROP INHERITS
Date
Msg-id 878xo7ju4m.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: ADD/DROP INHERITS  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: ADD/DROP INHERITS  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: ADD/DROP INHERITS  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
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 :(


-- 
greg



pgsql-hackers by date:

Previous
From: "Milen Kulev"
Date:
Subject: PG 8.2
Next
From: Andrew Dunstan
Date:
Subject: Re: PG 8.2