Hi, During the discussion in [1] an idea about refactoring ArchiveEntry was suggested. The reason is that currently this function has significant number of arguments that are "optional", and every change that has to deal with it introduces a lot of useless diffs. In the thread, mentioned above, such an example is tracking current table access method, and I guess "Remove WITH OIDS" commit 578b229718e is also similar.
Proposed idea is to refactor out all/optional arguments into a separate data structure, so that adding/removing a new argument wouldn't change that much of unrelated code. Then for every invocation of ArchiveEntry this structure needs to be prepared before the call, or as Andres suggested: ArchiveEntry((ArchiveArgs){.tablespace = 3, .dumpFn = somefunc, ...}); Another suggestion from Amit is to have an ArchiveEntry() function with limited number of parameters, and an ArchiveEntryEx() with those extra parameters which are not needed in usual cases. I want to prepare a patch for that, and I'm inclined to go with the first option, but since there are two solutions to choose from, I would love to hear more opinion about this topic. Any pros/cons we don't see yet? [1]: https://www.postgresql.org/message-id/flat/20180703070645.wchpu5muyto5n647%40alap3.anarazel.de