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 | 3aa | b | 2aa | a | 1bb | d
| 4bb | c | 3bb | b | 2bb | 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 | 3aa | b | 2aa | a | 1bb | c
| 4bb | d | 3bb | b | 2bb | 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
