"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> (1) We're talking about a new /bin executable to do this which
> could be referenced in an archive_command string or run from a
> script called by archive_command, right?
That, or an internal implementation. That would be a function in the
backend that would be called when archive_command is set to some
specific value, like for example test and cd are command lines referring
not to some executable on the PATH but to some internal code in bash.
But I know some people here will frown upon that idea.
> (2) It should copy, not move, with protection against overwriting
> an existing file.
See, we need to provide a good production grade facility. I've never
tried to do it myself, I'm just using walmgr to manage my archives.
> (3) Maybe not in the initial version, but eventually it might be
> nice to support URLs of some known protocols in addition to local
> directories.
I guess that if patches are provided in that direction it would be kind
of hard to refuse integrating them :)
> (4) Maybe not in the initial version, but eventually it might be
> nice to support checking for an "owner" file of some sort in the
> target directory, to help sort out problems with copied databases
> writing to the same location as the source.
Then we need to provide the associated restore command which must not be
one "owner" here I guess…
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support