Re: Improving test coverage of extensions with pg_dump - Mailing list pgsql-hackers

From Euler Taveira
Subject Re: Improving test coverage of extensions with pg_dump
Date
Msg-id 55FEB507.40901@timbira.com.br
Whole thread Raw
In response to Re: Improving test coverage of extensions with pg_dump  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: Improving test coverage of extensions with pg_dump  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On 17-09-2015 14:21, Michael Paquier wrote:
> pg_dump relies on attnum to define the column ordering, so one
> possibility would be to do things more consistently at backend level.
> Thoughts?
>
According to your example, problem is the columns from the parent table 
"aa" are added _before_ declaring the inherited table "bb". Then, an 
attnum from column "d" (part of parent table "aa") is assigned to a 
lower number than in the original table "bb".

Someone can say that we could assign an attnum for column "d" 
considering all of the inheritance tree. However, attnum is used as an 
index to arrays (we could bloat some of those) and some logic rely on it 
to count the number of columns. It would become tablecmds.c into an 
spaghetti.

IMHO a possible way to solve it is adding support for logical column 
ordering. An ALTER TABLE command (emitted if a parameter was informed) 
during dump could handle it. BTW, last thread [1] about logical column 
ordering seems to have died a few months ago. Alvaro?


[1] 
http://www.postgresql.org/message-id/20141209174146.GP1768@alvh.no-ip.org


--    Euler Taveira                   Timbira - http://www.timbira.com.br/   PostgreSQL: Consultoria, Desenvolvimento,
Suporte24x7 e Treinamento
 



pgsql-hackers by date:

Previous
From: "Adrian.Vondendriesch"
Date:
Subject: Re: [BUGS] BUG #12989: pg_size_pretty with negative values
Next
From: Petr Jelinek
Date:
Subject: Re: WIP: Rework access method interface