The attached patch adds some clarification to the documentation of the

binary format read/created by COPY BINARY. It also mentions the
contrib/binarycopy module.

Lee Kindness.

diff --git a/doc/src/sgml/ref/copy.sgml b/doc/src/sgml/ref/copy.sgml
index 0e24f8b3eec203206372fbdfaaddd5ca0de3fbea..c53a5f9251aa4a9601aab82bd5ed20e2021a5ee1 100644 (file)
--- a/doc/src/sgml/ref/copy.sgml
+++ b/doc/src/sgml/ref/copy.sgml
@@ -1,5 +1,5 @@
 
 
@@ -380,7 +380,7 @@ COPY table [ ( 
     The file format used for COPY BINARY changed in
     PostgreSQL 7.4. The new format consists
     of a file header, zero or more tuples containing the row data, and
-    a file trailer.
+    a file trailer. Headers and data are now in network byte order.
    
 
    
@@ -483,6 +483,15 @@ future extension may add a header field that allows per-column format codes
 to be specified.
     
 
+    
+To determine the appropriate binary format for the actual tuple data you
+should consult the PostgreSQL source, in
+particular the *send and *recv functions for
+the data type (typically found in the src/backend/utils/adt
+directory). The contrib/binarycopy module
+can also be used to create an appropriate format file.
+    
+
     
 If OIDs are included in the file, the OID field immediately follows the
 field-count word.  It is a normal field except that it's not included