On Thu, Sep 17, 2015 at 9:47 AM, Michael Paquier wrote: > COPY or INSERT include the column list in dumps, so that's not really > an issue here, what is potentially a problem (looking at that freshly) > is --inserts with data-only dumps though. So yes we had better fix it > and perhaps consider a backpatch...
When adding a column to a parent table, attnum gets confused on the child table... Take this example: =# create table aa (a int, b int); CREATE TABLE =# create table bb (c int) inherits (aa); CREATE TABLE =# alter table aa add column d text; ALTER TABLE =# select relname, attname, attnum from pg_attribute join pg_class on (attrelid = oid) where attrelid in( 'bb'::regclass, 'aa'::regclass) and attnum > 0; relname | attname | attnum ---------+---------+-------- aa | d | 3 aa | b | 2 aa | a | 1 bb | d | 4 bb | c | 3 bb | b | 2 bb | a | 1 (7 rows) When this is dumped and restored on another database the ordering gets different, c and d are switched for child relation bb here: relname | attname | attnum ---------+---------+-------- aa | d | 3 aa | b | 2 aa | a | 1 bb | c | 4 bb | d | 3 bb | b | 2 bb | a | 1 (7 rows) pg_dump relies on attnum to define the column ordering, so one possibility would be to do things more consistently at backend level. Thoughts? -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
