On Fri, Apr 10, 2020 at 3:38 PM Andres Freund <and...@anarazel.de> wrote: > Wouldn't there be state like a S3/ssh/https/... connection? And perhaps > a 'backup_id' in the backup metadata DB that'd one would want to update > at the end?
Good question. I don't know that there would be but, uh, maybe? It's not obvious to me why all of that would need to be done using the same connection, but if it is, the idea I proposed isn't going to work very nicely. More generally, can you think of any ideas for how to structure an API here that are easier to use than "write some C code"? Or do you think we should tell people to write some C code if they want to compress/encrypt/relocate their backup in some non-standard way? For the record, I'm not against eventually having more than one way to do this, maybe a shell-script interface for simpler things and some kind of API for more complex needs (e.g. NetBackup integration, perhaps). And I did wonder if there was some other way we could do this. For instance, we could add an option --tar-everything that sticks all the things that would have been returned by the backup inside another level of tar file and sends the result to stdout. Then you can pipe it into a single command that gets invoked only once for all the data, rather than once per tablespace. That might be better, but I'm not sure it's better. It's better if you want to do complicated things that involve steps that happen before and after and persistent connections and so on, but it seems worse for simple things like piping through a non-default compressor. Larry Wall somewhat famously commented that a good programming language should (and I paraphrase) make simple things simple and complex things possible. My hesitation in going straight to a C API is that it does not make simple things simple; and I'd like to be really sure that there is no way of achieving that valuable goal before we give up on it. However, there is no doubt that a C API is potentially more powerful. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company