Re: some more pg_dump refactoring
Fabien COELHO <coelho@cri.ensmp.fr>
From: Fabien COELHO <coelho@cri.ensmp.fr>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2020-07-08T04:42:14Z
Lists: pgsql-hackers
Hallo Peter, >>>> Would it make sense to accumulate in the other direction, older to newer, >>>> so that new attributes are added at the end of the select? >>> I think that could make sense, but the current style was introduced by >>> daa9fe8a5264a3f192efa5ddee8fb011ad9da365. Should we revise that? >> It seems to me more logical to do it while you're at it, but you are the >> one writing the patches:-) > > What do you think about this patch to reorganize the existing code from that > old commit? I think it is a definite further improvement. Patch applies cleanly, compiles, global & pg_dump tap test ok, looks ok to me. -- Fabien.
Commits
-
pg_dump: Reorganize dumpFunc() and dumpAgg()
- ed2c7f65bd9f 14.0 landed
-
pg_dump: Further reorganize getTableAttrs()
- 991c444e7ad3 14.0 landed
-
pg_dump: Reorganize getTableAttrs()
- daa9fe8a5264 12.0 cited