On 2019/04/23 20:03, David Rowley wrote:
> On Tue, 23 Apr 2019 at 18:18, Amit Langote
> <Langote_Amit_f8@lab.ntt.co.jp> wrote:
>>
>> If partitions needed a
>> map in the old database, this patch means that they will *continue* to
>> need it in the new database.
>
> That's incorrect.
Not completely though, because...
> My point was about dropped columns being removed
> after a dump / reload. Only binary upgrade mode preserves
> pg_attribute entries for dropped columns. Normal mode does not, so the
> maps won't be needed after the reload if they were previously only
> needed due to dropped columns. This is the case both with and without
> the pg_dump changes I proposed. The case the patch does change is if
> the columns were actually out of order, which I saw as an unlikely
> thing to happen in the real world.
This is the case I was talking about, which I agree is very rare. Sorry
for being unclear.
I think your proposed patch is fine and I don't want to argue that the way
things are now has some very sound basis.
Also, as you and Alvaro have found, the existing arrangement makes pg_dump
emit partitions in a way that's not super helpful (insert/copy failing
unintuitively), but it's not totally broken either. That said, I don't
mean to oppose back-patching any fix you think is appropriate.
Thank you for working on this.
Regards,
Amit