- The name of an open cursor to close.
- Message returned if the cursor is successfully closed.
- declared or has already been closed.
no longer needed.
+ The name of an open cursor to close.
- a cursor is considered open when it is declared.
+ Message returned if the cursor is successfully closed.
CLUSTER
SQL - Language Statements
+
-
- CLUSTER
-
-
- cluster a table according to an index
-
+ CLUSTER
+ cluster a table according to an index
+
-
- 1999-07-20
-
-
+
CLUSTER indexname ON tablename
CLUSTER tablename
CLUSTER
-
-
-
-
- 1998-09-08
-
-
- Inputs
-
-
-
-
- indexname
-
- The name of an index.
-
-
-
-
- table
-
- The name (possibly schema-qualified) of a table.
-
-
-
-
-
-
-
-
- 1998-09-08
-
-
- Outputs
-
-
-
-
-
-CLUSTER
-
-
- The clustering was done successfully.
-
-
-
-
-
-
+
-
-
- 1998-09-08
-
-
- Description
-
+
+
Description
+
CLUSTER instructs
PostgreSQL
to cluster the table specified
- by table
+ by tablename
based on the index specified by
indexname. The index must
already have been defined on
based on the index information. Clustering is a one-time operation:
when the table is subsequently updated, the changes are
not clustered. That is, no attempt is made to store new or
- updated tuples according to their index order. If one wishes, one can
- periodically re-cluster by issuing the command again.
+ updated rows according to their index order. If one wishes, one can
+ periodically recluster by issuing the command again.
When a table is clustered,
PostgreSQL
remembers on which index it was clustered. The form
CLUSTER tablename,
- re-clusters the table on the same index that it was clustered before.
+ reclusters the table on the same index that it was clustered before.
- CLUSTER without any parameter re-clusters all the tables
+ CLUSTER without any parameter reclusters all the tables
in the
current database that the calling user owns, or all tables if called
by a superuser. (Never-clustered tables are not included.) This
table until the CLUSTER is finished. See
for more information on database locking.
+
+
+
+
Parameter
+
+
+
+ indexname
+
+ The name of an index.
+
+
+
+
+
+ tablename
+
+ The name (possibly schema-qualified) of a table.
+
+
+
+
+
+
+
+
Diagnostics
+
+
+
+ CLUSTER
+
+ The clustering was done successfully.
+
+
+
+
+
-
-
- 1998-09-08
-
-
- Notes
-
+
+
Notes
In cases where you are accessing single rows randomly
- within a table, the actual order of the data in the heap
+ within a table, the actual order of the data in the
table is unimportant. However, if you tend to access some
data more than others, and there is an index that groups
them together, you will benefit from using CLUSTER.
-
-
- Another place where CLUSTER is helpful is in
- cases where you use an
- index to pull out several rows from a table. If you are
- requesting a range of indexed values from a table, or a
+ If you are requesting a range of indexed values from a table, or a
single indexed value that has multiple rows that match,
CLUSTER will help because once the index identifies the
heap page for the first row that matches, all other rows
that match are probably already on the same heap page,
- saving disk accesses and speeding up the query.
+ and so you save disk accesses and speed up the query.
sizes.
- CLUSTER preserves GRANT,
- inheritance, index, foreign key, and other ancillary information
- about the table.
-
-
Because CLUSTER remembers the clustering information,
one can cluster the tables one wants clustered manually the first time, and
setup a timed event similar to VACUUM so that the tables
- are periodically re-clustered.
+ are periodically reclustered.
- Because the optimizer records statistics about the ordering of tables, it
+ Because the planner records statistics about the ordering of tables, it
is advisable to run ANALYZE on the newly clustered
- table. Otherwise, the optimizer may make poor choices of query plans.
+ table. Otherwise, the planner may make poor choices of query plans.
but the majority of a big table will not fit in the cache.)
The other way to cluster a table is to use
-SELECT columnlist INTO TABLE newtable
- FROM table ORDER BY columnlist
-
+CREATE TABLE newtable AS
+ SELECT columnlist FROM table ORDER BY columnlist;
+
which uses the
PostgreSQL sorting code in
- the ORDER BY clause to create the desired order; this is usually much
+ the ORDER BY clause to create the desired order; this is usually much
faster than an index scan for
unordered data. You then drop the old table, use
- ALTER TABLE...RENAME
+ ALTER TABLE ... RENAME
to rename newtable to the old name, and
recreate the table's indexes. However, this approach does not preserve
OIDs, constraints, foreign key relationships, granted privileges, and
other ancillary properties of the table --- all such items must be
manually recreated.
-
-
-
-
- Usage
-
+
+
Examples
+
- Cluster the employees relation on the basis of
- its ID attribute:
-
+ Cluster the table employees on the basis of
+ its index emp_ind:
CLUSTER emp_ind ON emp;
-
+
+
+
Cluster the employees relation using the same
index that was used before:
-
CLUSTER emp;
-
+
+
+
Cluster all the tables on the database that have previously been clustered:
-
CLUSTER;
-
+
+
-
-
- Compatibility
-
-
-
-
- 1998-09-08
-
-
- SQL92
-
- There is no CLUSTER statement in SQL92.
-
-
+
+
Compatibility
+
+ There is no CLUSTER statement in the SQL standard.
+
COMMENT
SQL - Language Statements
+
-
- COMMENT
-
-
- define or change the comment of an object
-
+ COMMENT
+ define or change the comment of an object
+
-
- 1999-07-20
-
-
+
COMMENT ON
-[
+{
TABLE object_name |
COLUMN table_name.column_name |
AGGREGATE agg_name (agg_type) |
TRIGGER trigger_name ON table_name |
TYPE object_name |
VIEW object_name
-] IS 'text'
-
-
-
-
- 1999-10-25
-
-
- Inputs
-
-
-
-
- object_name,
- table_name.column_name, agg_name, constraint_name, func_name, op, rule_name, trigger_name
-
- The name of the object to be be commented. Names of tables,
- aggregates, domains, functions, indexes, operators, sequences, types,
- and views
- may be schema-qualified.
-
-
-
-
- text
-
- The comment to add.
-
-
-
-
-
-
-
-
-
- 1998-09-08
-
-
- Outputs
-
-
-
-
-
-COMMENT
-
-
- Message returned if the table is successfully commented.
-
-
-
-
-
-
+} IS 'text'
+
-
-
- 1998-10-25
-
-
- Description
-
+
+
Description
+
COMMENT stores a comment about a database object.
Comments can be
- easily retrieved with psql's
- \dd, \d+, or \l+
- commands. Other user interfaces to retrieve comments can be built atop
- the same built-in functions that <command>psql> uses, namely
- obj_description()> and col_description()>.
+ easily retrieved with
the psql commands
+ \dd, \d+, and \l+.
+ Other user interfaces to retrieve comments can be built atop
+ the same built-in functions that <application>psql> uses, namely
+ obj_description> and col_description>.
string.
Comments are automatically dropped when the object is dropped.
+
+
+
+
Parameters
+
+
+
+ object_name
+ table_name.column_name
+ aggname
+ constraint_name
+ func_name
+ op
+ rule_name
+ trigger_name
+
+ The name of the object to be be commented. Names of tables,
+ aggregates, domains, functions, indexes, operators, sequences,
+ types, and views may be schema-qualified.
+
+
+
+
+
+ text
+
+ The new comment.
+
+
+
+
+
+
+
+
Diagnostics
+
+
+
+ COMMENT
+
+ Message returned if the comment was successfully changed.
+
+
+
+
+
+
+
+
Notes
-
- There is presently no security mechanism
- for comments: any user connected to a database can see all the comments
- for objects in that database (although only superusers can change
- comments for objects that they don't own). Therefore, don't put
- security-critical information in comments.
+ There is presently no security mechanism for comments: any user
+ connected to a database can see all the comments for objects in
+ that database (although only superusers can change comments for
+ objects that they don't own). Therefore, don't put
+ security-critical information in comments.
-
-
-
- Usage
-
+
+
Examples
+
Attach a comment to the table mytable:
COMMENT ON TABLE mytable IS 'This is my table.';
-
+
Remove it again:
COMMENT ON TABLE mytable IS NULL;
-
+
Some more examples:
COMMENT ON AGGREGATE my_aggregate (double precision) IS 'Computes sample variance';
-COMMENT ON COLUMN my_table.my_field IS 'Employee ID number';
+COMMENT ON COLUMN my_table.my_column IS 'Employee ID number';
COMMENT ON DATABASE my_database IS 'Development Database';
COMMENT ON DOMAIN my_domain IS 'Email Address Domain';
COMMENT ON FUNCTION my_function (timestamp) IS 'Returns Roman Numeral';
-COMMENT ON INDEX my_index IS 'Enforces uniqueness on employee id';
+COMMENT ON INDEX my_index IS 'Enforces uniqueness on employee ID';
COMMENT ON OPERATOR ^ (text, text) IS 'Performs intersection of two texts';
COMMENT ON OPERATOR ^ (NONE, text) IS 'This is a prefix operator on text';
-COMMENT ON RULE my_rule ON my_table IS 'Logs UPDATES of employee records';
+COMMENT ON RULE my_rule ON my_table IS 'Logs updates of employee records';
COMMENT ON SCHEMA my_schema IS 'Departmental data';
COMMENT ON SEQUENCE my_sequence IS 'Used to generate primary keys';
COMMENT ON TABLE my_schema.my_table IS 'Employee Information';
-COMMENT ON TRIGGER my_trigger ON my_table IS 'Used for R.I.';
-COMMENT ON TYPE complex IS 'Complex Number datatype';
+COMMENT ON TRIGGER my_trigger ON my_table IS 'Used for RI';
+COMMENT ON TYPE complex IS 'Complex number data type';
COMMENT ON VIEW my_view IS 'View of departmental costs';
-
+
-
-
- Compatibility
-
-
-
-
- 1998-09-08
-
-
- SQL92
-
- There is no
COMMENT in
SQL92.
-
-
+
+
Compatibility
+
+ There is no COMMENT command in the SQL standard.
+
COPY
SQL - Language Statements
+
-
- COPY
-
-
- copy data between files and tables
-
+ COPY
+ copy data between files and tables
+
-
- 1999-12-11
-
-
+
COPY table [ ( column [, ...] ) ]
- FROM { 'filename' | stdin }
+ FROM { 'filename' | STDIN }
[ [ WITH ]
[ BINARY ]
[ OIDS ]
[ DELIMITER [ AS ] 'delimiter' ]
[ NULL [ AS ] 'null string' ] ]
+
COPY table [ ( column [, ...] ) ]
- TO { 'filename' | stdout }
+ TO { 'filename' | STDOUT }
[ [ WITH ]
[ BINARY ]
[ OIDS ]
[ DELIMITER [ AS ] 'delimiter' ]
[ NULL [ AS ] 'null string' ] ]
-
-
-
-
- 1998-09-08
-
-
- Inputs
-
-
-
-
- table
-
- The name (possibly schema-qualified) of an existing table.
-
-
-
-
-
- column
-
- An optional list of columns to be copied. If no column list is
- specified, all columns will be used.
-
-
-
-
-
- filename
-
- The absolute Unix path name of the input or output file.
-
-
-
-
-
- stdin
-
- Specifies that input comes from the client application.
-
-
-
-
-
- stdout
-
- Specifies that output goes to the client application.
-
-
-
-
-
- BINARY
-
- Changes the behavior of field formatting, forcing all data to be
- stored or read in binary format rather than as text. You can not
- specify or
- in binary mode.
-
-
-
-
-
- OIDS
-
- Specifies copying the internal object id (OID) for each row.
-
-
-
-
-
- delimiter
-
- The single character that separates fields within each row (line) of the file.
-
-
-
-
-
- null string
-
- The string that represents a NULL value. The default is
- \N
(backslash-N). You might
- prefer an empty string, for example.
-
-
- On a COPY FROM, any data item that matches
- this string will be stored as a NULL value, so you should
- make sure that you use the same string as you used with
- COPY TO.
-
-
-
-
-
-
-
-
-
-
-
- 1998-09-08
-
-
- Outputs
-
-
-
-
-
-COPY
-
-
- The copy completed successfully.
-
-
-
-
-
-ERROR: reason
-
-
- The copy failed for the reason stated in the error message.
-
-
-
-
-
-
+
-
-
- 2001-01-02
-
-
- Description
-
+
+
Description
+
COPY moves data between
PostgreSQL tables and standard file-system
COPY with a file name instructs the
-
PostgreSQL backend to directly read from
- or write to a file. The file must be accessible to the backend and
- the name must be specified from the viewpoint of the backend. When
- <filename>stdin or stdout> is
+
PostgreSQL server to directly read from
+ or write to a file. The file must be accessible to the server and
+ the name must be specified from the viewpoint of the server. When
+ <literal>STDIN or STDOUT> is
specified, data is transmitted via the connection between the
- client frontend and the backend.
-
-
+ client and the server.
+
+
+
+
+
Parameters
+
+
+
+ table
+
- Do not confuse COPY with the
- \copy. \copy invokes
- COPY FROM stdin or COPY TO
- stdout, and then fetches/stores the data in a file
- accessible to the
psql client. Thus,
- file accessibility and access rights depend on the client rather
- than the backend when \copy is used.
+ The name (possibly schema-qualified) of an existing table.
+
+
+
+
+
+ column
+
+ An optional list of columns to be copied. If no column list is
+ specified, all columns will be used.
+
+
+
+
+
+ filename
+
+ The absolute path name of the input or output file.
+
+
+
+
+
+ STDIN
+
+ Specifies that input comes from the client application.
+
+
+
+
+
+ STDOUT
+
+ Specifies that output goes to the client application.
+
+
+
+
+
+ BINARY
+
+ Forces all data to be stored or read in binary format rather
+ than as text. You cannot specify the
+ or options in binary mode.
+
+
+
+
+
+ OIDS
+
+ Specifies copying the OID for each row. (An error is raised if
+ OIDS is specified for a table that does not
+ have OIDs.)
+
+
+
+
+
+ delimiter
+
+ The single character that separates columns within each row
+ (line) of the file. The default is a tab character.
+
+
+
+
+
+ null string
+
+ The string that represents a null value. The default is
+ \N (backslash-N). You might prefer an empty
+ string, for example.
-
-
-
-
- 2001-01-02
-
-
- Notes
-
+
+ On a COPY FROM, any data item that matches
+ this string will be stored as a null value, so you should make
+ sure that you use the same string as you used with
+ COPY TO.
+
+
+
+
+
+
+
+
+
Diagnostics
+
+
+
+ COPY
+
+ The copy operation completed successfully.
+
+
+
+
+
+
+
+
Notes
+
COPY can only be used with plain tables, not
with views.
- The BINARY keyword will force all data to be
+ The BINARY key word will force all data to be
stored/read as binary format rather than as text. It is
- somewhat faster than the normal copy command, but a binary copy
+ somewhat faster than the normal text mode, but a binary format
file is not portable across machine architectures.
-
-
- By default, a text copy uses a tab ("\t") character as a delimiter
- between fields. The field delimiter may be changed to any other
- single character with the keyword . Characters
- in data fields that happen to match the delimiter character will be
- backslash quoted.
-
-
- You must have select privilege on any table
- whose values are read by COPY TO, and
- insert privilege on a table into which values
- are being inserted by COPY FROM. The backend also
- needs appropriate Unix permissions for any file read or written by
- COPY.
-
-
- COPY FROM will invoke any triggers and check
- constraints on the destination table. However, it will not invoke rules.
- COPY stops operation at the first error. This
- should not lead to problems in the event of a COPY
- TO, but the target relation will already have received
- earlier rows in a COPY FROM. These rows will not
- be visible or accessible, but they still occupy disk space. This may
- amount to a considerable amount of wasted disk space if the failure
- happened well into a large copy operation. You may wish to invoke
- VACUUM to recover the wasted space.
+ You must have select privilege on any table
+ whose values are read by COPY TO, and
+ insert privilege on a table into which values
+ are being inserted by COPY FROM.
Files named in a COPY command are read or written
- directly by the backend, not by the client application. Therefore,
+ directly by the server, not by the client application. Therefore,
they must reside on or be accessible to the database server machine,
not the client. They must be accessible to and readable or writable
by the
PostgreSQL user (the user ID the
server runs as), not the client. COPY naming a
file is only allowed to database superusers, since it allows reading
- or writing any file that the backend has privileges to access.
-
-
- The
- reads or writes files on the client machine with the client's
- permissions, so it is not restricted to superusers.
-
-
+ or writing any file that the server has privileges to access.
+
+
+ Do not confuse COPY with the
+ \copy. \copy invokes
+ COPY FROM STDIN or COPY TO
+ STDOUT, and then fetches/stores the data in a file
+ accessible to the
psql client. Thus,
+ file accessibility and access rights depend on the client rather
+ than the server when \copy is used.
It is recommended that the file name used in COPY
always be specified as an absolute path. This is enforced by the
- backend in the case of COPY TO, but for
+ server in the case of COPY TO, but for
COPY FROM you do have the option of reading from
a file specified by a relative path. The path will be interpreted
- relative to the backend's working directory (somewhere below
- $PGDATA), not the client's working directory.
+ relative to the working directory of the server process (somewhere below
+ the data directory), not the client's working directory.
+
+
+ COPY FROM will invoke any triggers and check
+ constraints on the destination table. However, it will not invoke rules.
+
+
+ COPY stops operation at the first error. This
+ should not lead to problems in the event of a COPY
+ TO, but the target table will already have received
+ earlier rows in a COPY FROM. These rows will not
+ be visible or accessible, but they still occupy disk space. This may
+ amount to a considerable amount of wasted disk space if the failure
+ happened well into a large copy operation. You may wish to invoke
+ VACUUM to recover the wasted space.
-
-
-
- 2001-01-02
-
+
File Formats
+
-
- 2002-02-12
-
Text Format
+
- When COPY is used without the BINARY option,
- the file read or written is a text file with one line per table row.
- Columns (attributes) in a row are separated by the delimiter character.
- The attribute values themselves are strings generated by the
+ When COPY is used without the BINARY option,
+ the data read or written is a text file with one line per table row.
+ Columns in a row are separated by the delimiter character.
+ The column values themselves are strings generated by the
output function, or acceptable to the input function, of each
attribute's data type. The specified null-value string is used in
- place of attributes that are NULL.
+ place of columns that are null.
COPY FROM will raise an error if any line of the
input file contains more or fewer columns than are expected.
+ If OIDS is specified, the OID is read or written as the first column,
+ preceding the user data columns.
- If OIDS is specified, the OID is read or written as the first column,
- preceding the user data columns. (An error is raised if OIDS is
- specified for a table that does not have OIDs.)
-
+
End of data can be represented by a single line containing just
backslash-period (\.>). An end-of-data marker is
- not necessary when reading from a Unix file, since the end of file
+ not necessary when reading from a file, since the end of file
serves perfectly well; but an end marker must be provided when copying
data to or from a client application.
+
Backslash characters (\>) may be used in the
COPY data to quote data characters that might
otherwise be taken as row or column delimiters. In particular, the
following characters must> be preceded by a backslash if
- they appear as part of an attribute value: backslash itself,
+ they appear as part of a column value: backslash itself,
newline, and the current delimiter character.
+
The following special backslash sequences are recognized by
COPY FROM:
backslash sequence, but it does use the other sequences listed above
for those control characters.
+
Never put a backslash before a data character N> or period
(.>). Such pairs will be mistaken for the default null string
or the end-of-data marker, respectively. Any other backslashed character
that is not mentioned in the above table will be taken to represent itself.
+
It is strongly recommended that applications generating COPY data convert
data newlines and carriage returns to the \n> and
- \r> sequences respectively. At present
- (
PostgreSQL 7.2 and older versions) it is
+ \r> sequences respectively. At present it is
possible to represent a data carriage return without any special quoting,
and to represent a data newline by a backslash and newline. However,
these representations will not be accepted by default in future releases.
+
Note that the end of each row is marked by a Unix-style newline
- ("\n"). Presently, COPY FROM will not behave as
+ (\n>>
). Presently, COPY FROM will not behave as
desired if given a file containing DOS- or Mac-style newlines.
This is expected to change in future releases.
-
- 2001-01-02
-
Binary Format
+
The file format used for COPY BINARY changed in
-
PostgreSQL v7.1. The new format consists
- of a file header, zero or more tuples, and a file trailer.
+
PostgreSQL 7.1. The new format consists
+ of a file header, zero or more tuples containing the row data, and
+ a file trailer.
-
- 2001-01-02
-
-
- File Header
-
+
File Header
+
The file header consists of 24 bytes of fixed fields, followed
by a variable-length header extension area. The fixed fields are:
Signature
-12-byte sequence PGBCOPY\n\377\r\n\0> --- note that the null
+12-byte sequence PGBCOPY\n\377\r\n\0> --- note that the zero byte
is a required part of the signature. (The signature is designed to allow
easy identification of files that have been munged by a non-8-bit-clean
transfer. This signature will be changed by newline-translation
-filters, dropped nulls, dropped high bits, or parity changes.)
+filters, dropped zero bytes, dropped high bits, or parity changes.)
Integer layout field
-int32 constant 0x01020304 in source's byte order. Potentially, a reader
+32-bit integer constant 0x01020304 in source's byte order. Potentially, a reader
could engage in byte-flipping of subsequent fields if the wrong byte
order is detected here.
Flags field
-int32 bit mask to denote important aspects of the file format. Bits are
+32-bit integer bit mask to denote important aspects of the file format. Bits are
numbered from 0 (
LSB>) to 31 (MSB>) --- note that this field is stored
with source's endianness, as are all subsequent integer fields. Bits
16-31 are reserved to denote critical file format issues; a reader
Bit 16
- if 1, OIDs are included in the dump; if 0, not
+ if 1, OIDs are included in the data; if 0, not
Header extension area length
-int32 length in bytes of remainder of header, not including self. In
-the initial version this will be zero, and the first tuple follows
+32-bit integer, length in bytes of remainder of header, not including self.
+Currently, this is zero, and the first tuple follows
immediately. Future changes to the format might allow additional data
to be present in the header. A reader should silently skip over any header
extension data it does not know what to do with.
-
- 2001-01-02
-
-
- Tuples
-
+
Tuples
-Each tuple begins with an int16 count of the number of fields in the
+Each tuple begins with a 16-bit integer count of the number of fields in the
tuple. (Presently, all tuples in a table will have the same count, but
that might not always be true.) Then, repeated for each field in the
-tuple, there is an int16 typlen> word possibly followed by field data.
+tuple, there is a 16-bit integer typlen> word possibly followed by field data.
The typlen> field is interpreted thus:
Zero
- Field is NULL. No data follows.
+ Field is null. No data follows.
> 0
- Field is a fixed-length data type. Exactly N
+ Field is a fixed-length data type. Exactly that many
bytes of data follow the typlen> word.
Field is a varlena> data type. The next four
bytes are the varlena> header, which contains
- the total value length including itself.
+ the total value length including the header itself.
-For non-NULL fields, the reader can check that the typlen> matches the
+For nonnull fields, the reader can check that the typlen> matches the
expected typlen> for the destination column. This provides a simple
but very useful check that the data is as expected.
-If OIDs are included in the dump, the OID field immediately follows the
+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
in the field-count. In particular it has a typlen> --- this will allow
-handling of 4-byte vs 8-byte OIDs without too much pain, and will allow
-OIDs to be shown as NULL if that ever proves desirable.
+handling of 4-byte vs. 8-byte OIDs without too much pain, and will allow
+OIDs to be shown as null if that ever proves desirable.
-
- 2001-01-02
-
-
- File Trailer
-
+
File Trailer
+
- The file trailer consists of an int16 word containing -1. This is
+ The file trailer consists of an 16-bit integer word containing -1. This is
easily distinguished from a tuple's field-count word.
-
-
- Usage
-
+
+
Examples
+
- The following example copies a table to standard output,
- using a vertical bar (|) as the field delimiter:
+ The following example copies a table to the client
+ using the vertical bar (|) as the field delimiter:
+COPY country TO STDOUT WITH DELIMITER '|';
+
-COPY country TO stdout WITH DELIMITER '|';
-
+
- To copy data from a Unix file into the country> table:
-
+ To copy data from a file into the country> table:
COPY country FROM '/usr1/proj/bray/sql/country_data';
-
+
+
+
Here is a sample of data suitable for copying into a table from
- <filename>stdin (so it has the termination sequence on the
+ <literal>STDIN (so it must have the termination sequence on the
last line):
-
AF AFGHANISTAN
AL ALBANIA
DZ ALGERIA
ZM ZAMBIA
ZW ZIMBABWE
\.
-
- Note that the white space on each line is actually a TAB.
+
+ Note that the white space on each line is actually a tab character.
+
The following is the same data, output in binary format on a
Linux/i586 machine. The data is shown after filtering through the
- Unix utility od -c. The table has three fields;
- the first is char(2), the second is text,
- and the third is integer. All the rows have a null value
- in the third field.
-
+ Unix utility od -c. The table has three columns;
+ the first has type char(2), the second has type text,
+ and the third has type integer. All the rows have a null value
+ in the third column.
0000000 P G B C O P Y \n 377 \r \n \0 004 003 002 001
0000020 \0 \0 \0 \0 \0 \0 \0 \0 003 \0 377 377 006 \0 \0 \0
0000040 A F 377 377 017 \0 \0 \0 A F G H A N I S
0000160 M 377 377 \n \0 \0 \0 Z A M B I A \0 \0 003
0000200 \0 377 377 006 \0 \0 \0 Z W 377 377 \f \0 \0 \0 Z
0000220 I M B A B W E \0 \0 377 377
-
+
+
-
-
- Compatibility
-
+
+
Compatibility
-
-
- 1998-09-08
-
-
- SQL92
-
- There is no COPY statement in SQL92.
-
- The following syntax was used by pre-7.3 applications and is still supported:
-
- COPY [ BINARY ] table [ WITH OIDS ]
- FROM { 'filename' | stdin }
- [ [USING] DELIMITERS 'delimiter' ]
- [ WITH NULL AS 'null string' ]
- COPY [ BINARY ] table [ WITH OIDS ]
- TO { 'filename' | stdout }
- [ [USING] DELIMITERS 'delimiter' ]
- [ WITH NULL AS 'null string' ]
-
-
-
+ There is no COPY statement in the SQL standard.
+
+
+ The following syntax was used before PostgreSQL version 7.3 and is
+ still supported:
+
+
+COPY [ BINARY ] table [ WITH OIDS ]
+ FROM { 'filename' | STDIN }
+ [ [USING] DELIMITERS 'delimiter' ]
+ [ WITH NULL AS 'null string' ]
+
+COPY [ BINARY ] table [ WITH OIDS ]
+ TO { 'filename' | STDOUT }
+ [ [USING] DELIMITERS 'delimiter' ]
+ [ WITH NULL AS 'null string' ]
+
+