COPY tablename [ ( column [, ...] ) ]
FROM { 'filename' | STDIN }
- [ [ WITH ]
+ [ [ WITH ]
[ BINARY ]
[ OIDS ]
[ DELIMITER [ AS ] 'delimiter' ]
[ NULL [ AS ] 'null string' ]
[ CSV [ HEADER ]
- [ QUOTE [ AS ] 'quote' ]
+ [ QUOTE [ AS ] 'quote' ]
[ ESCAPE [ AS ] 'escape' ]
[ FORCE NOT NULL column [, ...] ]
COPY { tablename [ ( column [, ...] ) ] | ( query ) }
TO { 'filename' | STDOUT }
- [ [ WITH ]
+ [ [ WITH ]
[ BINARY ]
[ OIDS ]
[ DELIMITER [ AS ] 'delimiter' ]
[ NULL [ AS ] 'null string' ]
[ CSV [ HEADER ]
- [ QUOTE [ AS ] 'quote' ]
+ [ QUOTE [ AS ] 'quote' ]
[ ESCAPE [ AS ] 'escape' ]
[ FORCE QUOTE { column [, ...] | * } ]
-
+
Description
client and the server.
-
+
Parameters
Specifies that the file contains a header line with the names of each
- column in the file. On output, the first line contains the column
+ column in the file. On output, the first line contains the column
names from the table, and on input, the first line is ignored.
In CSV> COPY TO> mode, forces quoting to be
used for all non-NULL> values in each specified column.
NULL> output is never quoted. If *> is specified,
- non-NULL> values for all columns of the table will be
+ non-NULL> values for all columns of the table will be
quoted.
somewhat faster than the normal text mode, but a binary-format
file is less portable across machine architectures and
+ Also, the binary format is very data type specific; for example
+ it will not work to output binary data from a smallint> column
+ and read it into an integer> column, even though that would work
+ fine in text format.
-
+
File Formats
- Presently, COPY TO will never emit an octal or
+ Presently, COPY TO will never emit an octal or
hex-digits backslash sequence, but it does use the other sequences
listed above for those control characters.
data newlines and carriage returns to the \n> and
\r> sequences respectively. At present it is
possible to represent a data carriage return by a backslash and carriage
- return, and to represent a data newline by a backslash and newline.
+ return, and to represent a data newline by a backslash and newline.
However, these representations might not be accepted in future releases.
They are also highly vulnerable to corruption if the COPY file is
transferred across different machines (for example, from Unix to Windows
- COPY TO will terminate each row with a Unix-style
+ COPY TO will terminate each row with a Unix-style
newline (\n>>). Servers running on Microsoft Windows instead
output carriage return/newline (\r\n>>), but only for
COPY> to a server file; for consistency across platforms,
non-NULL> values in specific columns.
The CSV> format has no standard way to distinguish a
NULL> value from an empty string.
PostgreSQL>'s COPY> handles this by
comparisons for specific columns.
Because backslash is not a special character in the CSV>
format, \.>, the end-of-data marker, could also appear
as a data value. To avoid any misinterpretation, a \.>
- data value appearing as a lone entry on a line is automatically
- quoted on output, and on input, if quoted, is not interpreted as the
+ data value appearing as a lone entry on a line is automatically
+ quoted on output, and on input, if quoted, is not interpreted as the
end-of-data marker. If you are loading a file created by another
- application that has a single unquoted column and might have a
- value of \.>, you might need to quote that value in the
+ application that has a single unquoted column and might have a
+ value of \.>, you might need to quote that value in the
input file.
- In CSV> mode, all characters are significant. A quoted value
- surrounded by white space, or any characters other than
- DELIMITER>, will include those characters. This can cause
- errors if you import data from a system that pads CSV>
- lines with white space out to some fixed width. If such a situation
- arises you might need to preprocess the CSV> file to remove
- the trailing white space, before importing the data into
+ In CSV> mode, all characters are significant. A quoted value
+ surrounded by white space, or any characters other than
+ DELIMITER>, will include those characters. This can cause
+ errors if you import data from a system that pads CSV>
+ lines with white space out to some fixed width. If such a situation
+ arises you might need to preprocess the CSV> file to remove
+ the trailing white space, before importing the data into
programs cannot process.
-
+
-
+
Examples
-
+
Compatibility
-
+
There is no COPY statement in the SQL standard.