On 2019/04/23 20:03, David Rowley wrote: > On Tue, 23 Apr 2019 at 18:18, Amit Langote > <langote_amit...@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
