-
+
Arrays
set to one. If any of an array's dimensions has a lower bound index not
equal to one, an additional decoration that indicates the actual
array dimensions will precede the array structure decoration.
- The decoration consists of square braces ([ and ])
- around each array dimension's lower and upper bound indices, plus
- a colon (:) delimiter character in between. Delimiting the
- array dimension decoration from the array structure decoration is a
- single assignment operator (=). For example:
+ This decoration consists of square brackets ([])
+ around each array dimension's lower and upper bounds, with
+ a colon (:) delimiter character in between. The
+ array dimension decoration is followed by an equal sign (=).
+ For example:
SELECT 1 || ARRAY[2,3] AS array;
- In a similar fashion, an array with non-default indices may be specified
- using the same literal syntax. For example:
+ This syntax can also be used to specify non-default array subscripts
+ in an array literal. For example:
SELECT f1[1][-2][3] AS e1, f1[1][-1][5] AS e2
FROM (SELECT '[1:1][-2:-1][3:5]={{{1,2,3},{4,5,6}}}'::int[] AS f1) AS ss;
You may write whitespace before a left brace or after a right
brace. You may also write whitespace before or after any individual item
string. In all of these cases the whitespace will be ignored. However,
- whitespace within double quoted elements, or surrounded on both sides by
- non-whitespace characters of an element, are not ignored.
+ whitespace within double-quoted elements, or surrounded on both sides by
+ non-whitespace characters of an element, is not ignored.
with a data type whose input routine also treated backslashes specially,
bytea for example, we might need as many as eight backslashes
in the command to get one backslash into the stored array element.)
+ Dollar quoting (see ) may be
+ used to avoid the need to double backslashes.
- shows all built-in general-purpose data types.
- Most of the alternative names
- listed in the
+ shows all the built-in general-purpose data
+ types. Most of the alternative names listed in the
Aliases
column are the names used internally by
PostgreSQL for historical reasons. In
addition, some internally used or deprecated types are available,
|
bytea
- binary data
+ binary data (byte array)
|
|
line
- infinite line in the plane (not fully implemented)
+ infinite line in the plane
|
s) ]
decimal [ (p,
s) ]
- exact numeric with selectable precision
+ exact numeric of selectable precision
|
path
- open or closed geometric path in the plane
+ geometric path in the plane
|
|
timestamp [ (p) ] [ without time zone ]
- <type></entry>
+
date and time
Each data type has an external representation determined by its input
and output functions. Many of the built-in types have
obvious external formats. However, several types are either unique
- to
PostgreSQL, such as
open and closed+ to
PostgreSQL, such as
geometric paths, or have several possibilities for formats, such as the date
and time types.
Some of the input and output functions are not invertible. That is,
the original input.
- Some of the operators and functions (e.g.,
- addition and multiplication) do not perform run-time error-checking in the
- interests of improving execution speed.
- On some systems, for example, the numeric operators for some data types may
- silently cause underflow or overflow.
-
-
Numeric Types
Numeric types consist of two-, four-, and eight-byte integers,
- four- and eight-byte floating-point numbers, and fixed-precision
+ four- and eight-byte floating-point numbers, and selectable-precision
decimals. lists the
available types.
created by reloading a dump from a pre-7.3 database; the dump
file does not contain the information needed to establish the
dependency link.) Furthermore, this dependency between sequence
- and column is made only for the serial column itself; if
+ and column is made only for the serial column itself. If
any other columns reference the sequence (perhaps by manually
calling the nextval function), they will be broken
if the sequence is removed. Using a serial column's sequence
varying(n) and
character(n), respectively.
character without length specifier is equivalent to
- character(1); if character varying is used
+ character(1). If character varying is used
without length specifier, the type accepts strings of any size. The
latter is a
PostgreSQL extension.
literal in an
SQL statement. In general, to
escape an octet, it is converted into the three-digit octal number
equivalent of its decimal octet value, and preceded by two
- backslashes. contains the
- characters which must be escaped, and gives the alternate escape
+ backslashes. shows the
+ characters that must be escaped, and gives the alternate escape
sequences where applicable.
Boxes are represented by pairs of points that are opposite
corners of the box.
- Values of type box is specified using the following syntax:
+ Values of type box are specified using the following syntax:
( ( x1 , y1 ) , ( x2 , y2 ) )
(x1,y1)
and
(x2,y2)
- are the opposite corners of the box.
+ are any two opposite corners of the box.
The corners are reordered on input to store
the upper right corner, then the lower left corner.
Other corners of the box can be entered, but the lower
- left and upper right corners are determined from the input and stored corners.
+ left and upper right corners are determined from the input and stored.
- Paths are represented by connected sets of points. Paths can be
+ Paths are represented by lists of connected points. Paths can be
open, where
- the first and last points in the set are not connected, and closed,
- where the first and last point are connected. The functions
- popen(p)
- and
- pclose(p)
- are supplied to force a path to be open or closed, and the functions
- isopen(p)
- and
- isclosed(p)
- are supplied to test for either type in an expression.
+ the first and last points in the list are not connected, or
+ closed,
+ where the first and last points are connected.
- Polygons are represented by sets of points. Polygons should probably be
+ Polygons are represented by lists of points (the vertexes of the
+ polygon). Polygons should probably be
considered equivalent to closed paths, but are stored differently
and have their own set of support routines.
PostgreSQL offers data types to store IPv4, IPv6, and MAC
- addresses, shown in . It
- is preferable to use these types over plain text types, because
+ addresses, as shown in . It
+ is preferable to use these types instead of plain text types to store
+ network addresses, because
these types offer input error checking and several specialized
operators and functions.
|
cidr
12 or 24 bytes
- IPv4 or IPv6 networks
+ IPv4 and IPv6 networks
|
the host address represent the network address (the
netmask
). If the netmask is 32 and the address is IPv4,
then the value does not indicate a subnet, only a single host.
- In IPv6, the address length is 128 bits, so 128 bits will specify a
+ In IPv6, the address length is 128 bits, so 128 bits specify a
unique host address. Note that if you
want to accept networks only, you should use the
cidr type rather than inet.
is the number of bits in the netmask. If the
/y
part is left off, then the
- netmask is 32 for IPv4 and 128 for IPv6, and the value represents
+ netmask is 32 for IPv4 and 128 for IPv6, so the value represents
just a single host. On display, the
/y
portion is suppressed if the netmask specifies a single host.
which would all specify the same
address. Upper and lower case is accepted for the digits
a through f. Output is always in the
- last of the shown forms.
+ last of the forms shown.
-
+
Data Definition
The identity (transaction ID) of the deleting transaction, or
zero for an undeleted row version. It is possible for this column to
- be nonzero in a visible row version: That usually indicates that the
+ be nonzero in a visible row version. That usually indicates that the
deleting transaction hasn't committed yet, or that an attempted
deletion was rolled back.
The tables in question should be created using WITH
OIDS to ensure forward compatibility with future
- releases of
PostgreSQL in which OIDs
- are not included in all tables by default.
+ releases of
PostgreSQL. It is
+ planned that WITHOUT OIDS will become the default.
created and no values are specified for some of the columns, the
columns will be filled with their respective default values. A
data manipulation command can also request explicitly that a column
- be set to its default value, without knowing what this value is.
+ be set to its default value, without having to know what that value is.
(Details about data manipulation commands are in .)
- If no default value is declared explicitly, the null value is the
- default value. This usually makes sense because a null value can
- be thought to represent unknown data.
+ If no default value is declared explicitly, the default value is the
+ null value. This usually makes sense because a null value can
+ be considered to represent unknown data.
The default value may be a scalar expression, which will be
evaluated whenever the default value is inserted
- (not when the table is created).
+ (not when the table is created). A common example
+ is that a timestamp column may have a default of now(),
+ so that it gets set to the time of row insertion.
expressions will evaluate to the null value if one operand is null,
they will not prevent null values in the constrained columns. To
ensure that a column does not contain null values, the not-null
- constraint described in the next section should be used.
+ constraint described in the next section can be used.
- In general, a unique constraint is violated when there are (at
- least) two rows in the table where the values of each of the
- corresponding columns that are part of the constraint are equal.
+ In general, a unique constraint is violated when there are two or
+ more rows in the table where the values of all of the
+ columns included in the constraint are equal.
However, null values are not considered equal in this
- consideration. That means even in the presence of a
+ comparison. That means even in the presence of a
unique constraint it is possible to store an unlimited number of
rows that contain a null value in at least one of the constrained
columns. This behavior conforms to the SQL standard, but we have
);
because in absence of a column list the primary key of the
- referenced table is used as the referenced column.
+ referenced table is used as the referenced column(s).
We know that the foreign keys disallow creation of orders that
do not relate to any products. But what if a product is removed
after an order is created that references it? SQL allows you to
- specify that as well. Intuitively, we have a few options:
+ handle that as well. Intuitively, we have a few options:
Disallow deleting a referenced product
Delete the orders as well
Restricting and cascading deletes are the two most common options.
- RESTRICT prevents a statement from deleting a
+ RESTRICT prevents deletion of a
referenced row. NO ACTION means that if any
referencing rows still exist when the constraint is checked, an error
- is raised; this is the default if you do not specify anything.
- (The essential difference between these choices is that
+ is raised; this is the default behavior if you do not specify anything.
+ (The essential difference between these two choices is that
NO ACTION allows the check to be deferred until
later in the transaction, whereas RESTRICT does not.)
+ CASCADE specifies that when a referenced row is deleted,
+ row(s) referencing it should be automatically deleted as well.
There are two other options:
SET NULL and SET DEFAULT.
These cause the referencing columns to be set to nulls or default
Note that these do not excuse you from observing any constraints.
For example, if an action specifies SET DEFAULT
but the default value would not satisfy the foreign key, the
- deletion of the primary key will fail.
+ operation will fail.
Analogous to ON DELETE there is also
- ON UPDATE which is invoked when a primary key
- is changed (updated). The possible actions are the same.
+ ON UPDATE which is invoked when a referenced
+ column is changed (updated). The possible actions are the same.
+
+
Change column data types,+
- All these actions are performed using the ALTER
- TABLE command.
+ All these actions are performed using the
+
+ command.
-
Changing <span class="marked">the Default</span>
+
Changing <span class="marked">a Column's Default Value</span>
+
+
Changing a Column's Data Type
+
+
+ changing
+
+
+ To convert a column to a different data type, use a command like this:
+ALTER TABLE products ALTER COLUMN price TYPE numeric(10,2);
+
+ This will succeed only if each existing entry in the column can be
+ converted to the new type by an implicit cast. If a more complex
+ conversion is needed, you can add a USING clause that
+ specifies how to compute the new values from the old.
+
+
+
PostgreSQL will attempt to convert the column's+ default value (if any) to the new type, as well as any constraints
+ that involve the column. But these conversions may fail, or may
+ produce surprising results. It's often best to drop any constraints
+ on the column before altering its type, and then add back suitably
+ modified constraints afterwards.
+
+
+
Renaming a Column
- To create a separate schema, use the command CREATE
+ To create a schema, use the command CREATE
SCHEMA. Give the schema a name of your choice. For
example:
(The first public
is the schema, the second
public
means every user
. In the
first sense it is an identifier, in the second sense it is a
- reserved word, hence the different capitalization; recall the
+ key word, hence the different capitalization; recall the
guidelines from .)
-
+
Data Manipulation
- Let's look at that command in detail: First is the key word
+ Let's look at that command in detail. First is the key word
UPDATE followed by the table name. As usual,
the table name may be schema-qualified, otherwise it is looked up
in the path. Next is the key word SET followed
UPDATE products SET price = price * 1.10;
- As you see, the expression for the new value can also refer to the
- old value. We also left out the WHERE clause.
+ As you see, the expression for the new value can refer to the existing
+ value(s) in the row. We also left out the WHERE clause.
If it is omitted, it means that all rows in the table are updated.
- If it is present, only those rows that match the condition after
- the WHERE are updated. Note that the equals
+ If it is present, only those rows that match the
+ WHERE condition are updated. Note that the equals
sign in the SET clause is an assignment while
the one in the WHERE clause is a comparison, but
- this does not create any ambiguity. Of course, the condition does
+ this does not create any ambiguity. Of course, the
+ WHERE condition does
not have to be an equality test. Many other operators are
available (see ). But the expression
needs to evaluate to a Boolean result.
- You can also update more than one column in an
+ You can update more than one column in an
UPDATE command by listing more than one
assignment in the SET clause. For example:
change data. What remains is to discuss how to remove data that is
no longer needed. Just as adding data is only possible in whole
rows, you can only remove entire rows from a table. In the
- previous section we discussed that SQL does not provide a way to
+ previous section we explained that SQL does not provide a way to
directly address individual rows. Therefore, removing rows can
only be done by specifying conditions that the rows to be removed
have to match. If you have a primary key in the table then you can
describes the installation and
- administration of the server. Everyone that runs a
+ administration of the server. Everyone who runs a
PostgreSQL server, be it for private
use or for others, should read this part.
- contains information about the syntax
- of SQL commands, client and server programs. This part supports
+ contains reference information about
+ SQL commands, client and server programs. This part supports
the other parts with structured information sorted by command or
program.
- contains assorted information that can be of
+ contains assorted information that may be of
use to
PostgreSQL developers.
explain how to create the structures to hold data, how to populate
the database, and how to query it. The middle part lists the
available data types and functions for use in
-
SQL data commands. The rest treats several
+
SQL commands. The rest treats several
aspects that are important for tuning a database for optimal
performance.
-
+
Queries
A temporary name can be given to tables and complex table
references to be used for references to the derived table in
- further processing. This is called a table
+ the rest of the query. This is called a table
alias.
- Another form of table aliasing also gives temporary names to the columns of the table:
+ Another form of table aliasing gives temporary names to the columns of
+ the table, as well as the table itself:
FROM table_reference AS alias ( column1 , column2 , ... )
where z.fooid = foo.fooid);
CREATE VIEW vw_getfoo AS SELECT * FROM getfoo(1);
+
SELECT * FROM vw_getfoo;
The syntax of the
- endterm="sql-where-title"> clause is
+ endterm="sql-where-title"> is
WHERE search_condition
where search_condition is any value
- expression as defined in that
+ expression (see ) that
returns a value of type boolean.
condition. If the result of the condition is true, the row is
kept in the output table, otherwise (that is, if the result is
false or null) it is discarded. The search condition typically
- references at least some column in the table generated in the
+ references at least some column of the table generated in the
FROM clause; this is not required, but otherwise the
WHERE clause will be fairly useless.
- Before the implementation of the JOIN syntax, it was
- necessary to put the join condition of an inner join in the
- WHERE clause. For example, these table expressions
- are equivalent:
+ The join condition of an inner join can be written either in
+ the WHERE clause or in the JOIN clause.
+ For example, these table expressions are equivalent:
FROM a, b WHERE a.id = b.id AND b.val > 5
The is
used to group together those rows in a table that share the same
values in all the columns listed. The order in which the columns
- are listed does not matter. The purpose is to reduce each group
+ are listed does not matter. The effect is to combine each set
of rows sharing common values into one group row that is
representative of all rows in the group. This is done to
eliminate redundancy in the output and/or compute aggregates that
FROM test1 GROUP BY x, because there is no single value
for the column y that could be associated with each
group. The grouped-by columns can be referenced in the select list since
- they have a known constant value per group.
+ they have a single value in each group.
After the select list has been processed, the result table may
- optionally be subject to the elimination of duplicates. The
- DISTINCT key word is written directly after the
- SELECT to enable this:
+ optionally be subject to the elimination of duplicate rows. The
+ DISTINCT key word is written directly after
+ SELECT to specify this:
SELECT DISTINCT select_list ...
(Instead of DISTINCT the key word ALL
- can be used to select the default behavior of retaining all rows.)
+ can be used to specify the default behavior of retaining all rows.)
query2 to the result of
query1 (although there is no guarantee
that this is the order in which the rows are actually returned).
- Furthermore, it eliminates all duplicate rows, in the sense of
- DISTINCT, unless UNION ALL is used.
+ Furthermore, it eliminates duplicate rows from its result, in the same
+ way as DISTINCT, unless UNION ALL is used.
In order to calculate the union, intersection, or difference of two
queries, the two queries must be union compatible
,
- which means that they both return the same number of columns, and
- that the corresponding columns have compatible data types, as
+ which means that they return the same number of columns and
+ the corresponding columns have compatible data types, as
described in .
After a query has produced an output table (after the select list
has been processed) it can optionally be sorted. If sorting is not
- chosen, the rows will be returned in random order. The actual
+ chosen, the rows will be returned in an unspecified order. The actual
order in that case will depend on the scan and join plan types and
the order on disk, but it must not be relied on. A particular
output ordering can only be guaranteed if the sort step is explicitly
SELECT a, b FROM table1 ORDER BY a + b;
- References to column names in the FROM clause that are
- renamed in the select list are also allowed:
+ References to column names of the FROM clause that are
+ not present in the select list are also allowed:
-SELECT a AS b FROM table1 ORDER BY a;
+SELECT a FROM table1 ORDER BY b;
But these extensions do not work in queries involving
UNION, INTERSECT, or EXCEPT,
deliver the results of a query in any particular order unless
ORDER BY is used to constrain the order.
+
+ The rows skipped by an OFFSET clause still have to be
+ computed inside the server; therefore a large OFFSET
+ can be inefficient.
+
-
+
Composite Types
with a data type whose input routine also treated backslashes specially,
bytea for example, we might need as many as eight backslashes
in the command to get one backslash into the stored composite field.)
+ Dollar quoting (see ) may be
+ used to avoid the need to double backslashes.
A dollar sign ($) followed by digits is used
to represent a positional parameter in the body of a function
definition or a prepared statement. In other contexts the
- dollar sign may be part of an identifier.
+ dollar sign may be part of an identifier or a dollar-quoted string
+ constant.
- The asterisk (*) has a special meaning when
- used in the SELECT command or with the
+ The asterisk (*) is used in some contexts to denote
+ all the fields of a table row or composite value. It also
+ has a special meaning when used as the argument of the
COUNT aggregate function.
|
BETWEEN
- containment
+ range containment
|
CREATE FUNCTION dept(text) RETURNS dept
- AS $$SELECT * FROM dept WHERE name = $1$$
+ AS $$ SELECT * FROM dept WHERE name = $1 $$
LANGUAGE SQL;
to avoid ambiguity. For example:
CREATE TABLE mytable(f1 int, f2 float, f3 text);
+
CREATE FUNCTION getf1(mytable) RETURNS int AS 'SELECT $1.f1' LANGUAGE SQL;
+
-- No cast needed since only one getf1() exists
SELECT getf1(ROW(1,2.5,'this is a test'));
getf1
(1 row)
CREATE TYPE myrowtype AS (f1 int, f2 text, f3 numeric);
+
CREATE FUNCTION getf1(myrowtype) RETURNS int AS 'SELECT $1.f1' LANGUAGE SQL;
+
-- Now we need a cast to indicate which function to call:
SELECT getf1(ROW(1,2.5,'this is a test'));
ERROR: function getf1(record) is not unique
+
SELECT getf1(ROW(1,2.5,'this is a test')::mytable);
getf1
-------
IS NULL or IS NOT NULL, for example
SELECT ROW(1,2.5,'this is a test') = ROW(1, 3, 'not the same');
+
SELECT ROW(a, b, c) IS NOT NULL FROM table;
For more detail see .
projects / postgresql.git / commitdiff