On Tue, Jun 15, 2021 at 11:33:10AM -0400, Stephen Frost wrote: > > The requirements are things which are learned over years and changes > over time. Trying to document them and keep up with them would be a > pretty serious project all on its own. There are external projects who > spend serious time and energy doing their best to provide the tooling > needed here and we should be promoting those, not trying to pretend like > this is a simple thing which anyone could write a short perl script to > accomplish.
The fact that this is such a complex problem is the very reason why we should spend a lot of energy documenting the various requirements. Otherwise, how could anyone implement a valid program for that and how could anyone validate that a solution claiming to do its job actually does its job? > Already tried doing it in perl. No, it's not simple and it's also > entirely vaporware today and implies that we're going to develop this > tool, improve it in the future as we realize it needs to be improved, > and maintain it as part of core forever. If we want to actually adopt > and pull in a backup tool to be part of core then we should talk about > things which actually exist, such as the various existing projects that > have been written to specifically work to address all the requirements > which are understood today, not say "well, we can just write a simple > perl script to do it" because it's not actually that simple. Adopting a full backup solution seems like a bit extreme. On the other hand, having some real core implementation of an archive_command for the most general use cases (local copy, distant copy over ssh...) could make sense. This would remove that burden for some, probably most, of the 3rd party backup tools, and would also ensure that the various requirements are properly documented since it would be the implementation reference.
