On 3/26/21 1:20 PM, Magnus Hagander wrote:
On Fri, Mar 26, 2021 at 5:52 PM Andrew Dunstan <and...@dunslane.net> wrote:
On 3/26/21 10:19 AM, David Steele wrote:
No, the problem is you are using copy/paste and in doing so you are
*changing'* the value that is being returned. You'll either need to
update your copy/paste procedure to not mess with the newlines, or to
use a better way to get the data out.
If we need to clarify that in the documentation, I'm fine with that.
Maybe add an extra sentence to the part about not modifying the output
to mention that this includes changing newslines and also encoding
(which would also break it, if you managed to find a non-ascii
compatible encoding). Maybe even something along the line of "the
contents have to be written in binary mode"?
Perhaps something like the attached?
That seems a bit opaque. Let's tell them exactly what they need to avoid.
Yeah, it seems a bit imprecise. Maybe something like "which includes
things like opening the file in binary mode"? (I want the "includes"
part because it also means other things, this is not the only thing).
OK, how about the attached?
Regards,
--
-David
da...@pgmasters.net
diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
index c5557d5444..b1899135c8 100644
--- a/doc/src/sgml/backup.sgml
+++ b/doc/src/sgml/backup.sgml
@@ -913,7 +913,8 @@ SELECT * FROM pg_stop_backup(false, true);
<filename>backup_label</filename> in the root directory of the backup. The
third field should be written to a file named
<filename>tablespace_map</filename> unless the field is empty. These
files are
- vital to the backup working, and must be written without modification.
+ vital to the backup working and must be written without modification,
which
+ may include opening the file in binary mode.
</para>
</listitem>
<listitem>
