Re: Improving test coverage of extensions with pg_dump

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