2020 lines
84 KiB
Plaintext
2020 lines
84 KiB
Plaintext
<!--
|
|
doc/src/sgml/ref/select.sgml
|
|
PostgreSQL documentation
|
|
-->
|
|
|
|
<refentry id="SQL-SELECT">
|
|
<indexterm zone="sql-select">
|
|
<primary>SELECT</primary>
|
|
</indexterm>
|
|
|
|
<indexterm zone="sql-select">
|
|
<primary>TABLE command</primary>
|
|
</indexterm>
|
|
|
|
<indexterm zone="sql-select">
|
|
<primary>WITH</primary>
|
|
<secondary>in SELECT</secondary>
|
|
</indexterm>
|
|
|
|
<refmeta>
|
|
<refentrytitle>SELECT</refentrytitle>
|
|
<manvolnum>7</manvolnum>
|
|
<refmiscinfo>SQL - Language Statements</refmiscinfo>
|
|
</refmeta>
|
|
|
|
<refnamediv>
|
|
<refname>SELECT</refname>
|
|
<refname>TABLE</refname>
|
|
<refname>WITH</refname>
|
|
<refpurpose>retrieve rows from a table or view</refpurpose>
|
|
</refnamediv>
|
|
|
|
<refsynopsisdiv>
|
|
<synopsis>
|
|
[ WITH [ RECURSIVE ] <replaceable class="parameter">with_query</replaceable> [, ...] ]
|
|
SELECT [ ALL | DISTINCT [ ON ( <replaceable class="parameter">expression</replaceable> [, ...] ) ] ]
|
|
[ * | <replaceable class="parameter">expression</replaceable> [ [ AS ] <replaceable class="parameter">output_name</replaceable> ] [, ...] ]
|
|
[ FROM <replaceable class="parameter">from_item</replaceable> [, ...] ]
|
|
[ WHERE <replaceable class="parameter">condition</replaceable> ]
|
|
[ GROUP BY <replaceable class="parameter">grouping_element</replaceable> [, ...] ]
|
|
[ HAVING <replaceable class="parameter">condition</replaceable> [, ...] ]
|
|
[ WINDOW <replaceable class="parameter">window_name</replaceable> AS ( <replaceable class="parameter">window_definition</replaceable> ) [, ...] ]
|
|
[ { UNION | INTERSECT | EXCEPT } [ ALL | DISTINCT ] <replaceable class="parameter">select</replaceable> ]
|
|
[ ORDER BY <replaceable class="parameter">expression</replaceable> [ ASC | DESC | USING <replaceable class="parameter">operator</replaceable> ] [ NULLS { FIRST | LAST } ] [, ...] ]
|
|
[ LIMIT { <replaceable class="parameter">count</replaceable> | ALL } ]
|
|
[ OFFSET <replaceable class="parameter">start</replaceable> [ ROW | ROWS ] ]
|
|
[ FETCH { FIRST | NEXT } [ <replaceable class="parameter">count</replaceable> ] { ROW | ROWS } ONLY ]
|
|
[ FOR { UPDATE | NO KEY UPDATE | SHARE | KEY SHARE } [ OF <replaceable class="parameter">table_name</replaceable> [, ...] ] [ NOWAIT | SKIP LOCKED ] [...] ]
|
|
|
|
<phrase>where <replaceable class="parameter">from_item</replaceable> can be one of:</phrase>
|
|
|
|
[ ONLY ] <replaceable class="parameter">table_name</replaceable> [ * ] [ [ AS ] <replaceable class="parameter">alias</replaceable> [ ( <replaceable class="parameter">column_alias</replaceable> [, ...] ) ] ]
|
|
[ TABLESAMPLE <replaceable class="parameter">sampling_method</replaceable> ( <replaceable class="parameter">argument</replaceable> [, ...] ) [ REPEATABLE ( <replaceable class="parameter">seed</replaceable> ) ] ]
|
|
[ LATERAL ] ( <replaceable class="parameter">select</replaceable> ) [ AS ] <replaceable class="parameter">alias</replaceable> [ ( <replaceable class="parameter">column_alias</replaceable> [, ...] ) ]
|
|
<replaceable class="parameter">with_query_name</replaceable> [ [ AS ] <replaceable class="parameter">alias</replaceable> [ ( <replaceable class="parameter">column_alias</replaceable> [, ...] ) ] ]
|
|
[ LATERAL ] <replaceable class="parameter">function_name</replaceable> ( [ <replaceable class="parameter">argument</replaceable> [, ...] ] )
|
|
[ WITH ORDINALITY ] [ [ AS ] <replaceable class="parameter">alias</replaceable> [ ( <replaceable class="parameter">column_alias</replaceable> [, ...] ) ] ]
|
|
[ LATERAL ] <replaceable class="parameter">function_name</replaceable> ( [ <replaceable class="parameter">argument</replaceable> [, ...] ] ) [ AS ] <replaceable class="parameter">alias</replaceable> ( <replaceable class="parameter">column_definition</replaceable> [, ...] )
|
|
[ LATERAL ] <replaceable class="parameter">function_name</replaceable> ( [ <replaceable class="parameter">argument</replaceable> [, ...] ] ) AS ( <replaceable class="parameter">column_definition</replaceable> [, ...] )
|
|
[ LATERAL ] ROWS FROM( <replaceable class="parameter">function_name</replaceable> ( [ <replaceable class="parameter">argument</replaceable> [, ...] ] ) [ AS ( <replaceable class="parameter">column_definition</replaceable> [, ...] ) ] [, ...] )
|
|
[ WITH ORDINALITY ] [ [ AS ] <replaceable class="parameter">alias</replaceable> [ ( <replaceable class="parameter">column_alias</replaceable> [, ...] ) ] ]
|
|
<replaceable class="parameter">from_item</replaceable> [ NATURAL ] <replaceable class="parameter">join_type</replaceable> <replaceable class="parameter">from_item</replaceable> [ ON <replaceable class="parameter">join_condition</replaceable> | USING ( <replaceable class="parameter">join_column</replaceable> [, ...] ) ]
|
|
|
|
<phrase>and <replaceable class="parameter">grouping_element</replaceable> can be one of:</phrase>
|
|
|
|
( )
|
|
<replaceable class="parameter">expression</replaceable>
|
|
( <replaceable class="parameter">expression</replaceable> [, ...] )
|
|
ROLLUP ( { <replaceable class="parameter">expression</replaceable> | ( <replaceable class="parameter">expression</replaceable> [, ...] ) } [, ...] )
|
|
CUBE ( { <replaceable class="parameter">expression</replaceable> | ( <replaceable class="parameter">expression</replaceable> [, ...] ) } [, ...] )
|
|
GROUPING SETS ( <replaceable class="parameter">grouping_element</replaceable> [, ...] )
|
|
|
|
<phrase>and <replaceable class="parameter">with_query</replaceable> is:</phrase>
|
|
|
|
<replaceable class="parameter">with_query_name</replaceable> [ ( <replaceable class="parameter">column_name</replaceable> [, ...] ) ] AS ( <replaceable class="parameter">select</replaceable> | <replaceable class="parameter">values</replaceable> | <replaceable class="parameter">insert</replaceable> | <replaceable class="parameter">update</replaceable> | <replaceable class="parameter">delete</replaceable> )
|
|
|
|
TABLE [ ONLY ] <replaceable class="parameter">table_name</replaceable> [ * ]
|
|
</synopsis>
|
|
|
|
</refsynopsisdiv>
|
|
|
|
<refsect1>
|
|
<title>Description</title>
|
|
|
|
<para>
|
|
<command>SELECT</command> retrieves rows from zero or more tables.
|
|
The general processing of <command>SELECT</command> is as follows:
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>
|
|
All queries in the <literal>WITH</literal> list are computed.
|
|
These effectively serve as temporary tables that can be referenced
|
|
in the <literal>FROM</literal> list. A <literal>WITH</literal> query
|
|
that is referenced more than once in <literal>FROM</literal> is
|
|
computed only once.
|
|
(See <xref linkend="sql-with" endterm="sql-with-title"> below.)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
All elements in the <literal>FROM</literal> list are computed.
|
|
(Each element in the <literal>FROM</literal> list is a real or
|
|
virtual table.) If more than one element is specified in the
|
|
<literal>FROM</literal> list, they are cross-joined together.
|
|
(See <xref linkend="sql-from" endterm="sql-from-title"> below.)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
If the <literal>WHERE</literal> clause is specified, all rows
|
|
that do not satisfy the condition are eliminated from the
|
|
output. (See <xref linkend="sql-where"
|
|
endterm="sql-where-title"> below.)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
If the <literal>GROUP BY</literal> clause is specified,
|
|
or if there are aggregate function calls, the
|
|
output is combined into groups of rows that match on one or more
|
|
values, and the results of aggregate functions are computed.
|
|
If the <literal>HAVING</literal> clause is present, it
|
|
eliminates groups that do not satisfy the given condition. (See
|
|
<xref linkend="sql-groupby" endterm="sql-groupby-title"> and
|
|
<xref linkend="sql-having" endterm="sql-having-title"> below.)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
The actual output rows are computed using the
|
|
<command>SELECT</command> output expressions for each selected
|
|
row or row group. (See
|
|
<xref linkend="sql-select-list" endterm="sql-select-list-title">
|
|
below.)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><literal>SELECT DISTINCT</literal> eliminates duplicate rows from the
|
|
result. <literal>SELECT DISTINCT ON</literal> eliminates rows that
|
|
match on all the specified expressions. <literal>SELECT ALL</literal>
|
|
(the default) will return all candidate rows, including
|
|
duplicates. (See <xref linkend="sql-distinct"
|
|
endterm="sql-distinct-title"> below.)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Using the operators <literal>UNION</literal>,
|
|
<literal>INTERSECT</literal>, and <literal>EXCEPT</literal>, the
|
|
output of more than one <command>SELECT</command> statement can
|
|
be combined to form a single result set. The
|
|
<literal>UNION</literal> operator returns all rows that are in
|
|
one or both of the result sets. The
|
|
<literal>INTERSECT</literal> operator returns all rows that are
|
|
strictly in both result sets. The <literal>EXCEPT</literal>
|
|
operator returns the rows that are in the first result set but
|
|
not in the second. In all three cases, duplicate rows are
|
|
eliminated unless <literal>ALL</literal> is specified. The noise
|
|
word <literal>DISTINCT</> can be added to explicitly specify
|
|
eliminating duplicate rows. Notice that <literal>DISTINCT</> is
|
|
the default behavior here, even though <literal>ALL</literal> is
|
|
the default for <command>SELECT</> itself. (See
|
|
<xref linkend="sql-union" endterm="sql-union-title">, <xref
|
|
linkend="sql-intersect" endterm="sql-intersect-title">, and
|
|
<xref linkend="sql-except" endterm="sql-except-title"> below.)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
If the <literal>ORDER BY</literal> clause is specified, the
|
|
returned rows are sorted in the specified order. If
|
|
<literal>ORDER BY</literal> is not given, the rows are returned
|
|
in whatever order the system finds fastest to produce. (See
|
|
<xref linkend="sql-orderby" endterm="sql-orderby-title"> below.)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
If the <literal>LIMIT</literal> (or <literal>FETCH FIRST</literal>) or <literal>OFFSET</literal>
|
|
clause is specified, the <command>SELECT</command> statement
|
|
only returns a subset of the result rows. (See <xref
|
|
linkend="sql-limit" endterm="sql-limit-title"> below.)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
If <literal>FOR UPDATE</>, <literal>FOR NO KEY UPDATE</literal>, <literal>FOR SHARE</literal>
|
|
or <literal>FOR KEY SHARE</literal>
|
|
is specified, the
|
|
<command>SELECT</command> statement locks the selected rows
|
|
against concurrent updates. (See <xref linkend="sql-for-update-share"
|
|
endterm="sql-for-update-share-title"> below.)
|
|
</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</para>
|
|
|
|
<para>
|
|
You must have <literal>SELECT</literal> privilege on each column used
|
|
in a <command>SELECT</> command. The use of <literal>FOR NO KEY UPDATE</>,
|
|
<literal>FOR UPDATE</literal>,
|
|
<literal>FOR SHARE</literal> or <literal>FOR KEY SHARE</literal> requires
|
|
<literal>UPDATE</literal> privilege as well (for at least one column
|
|
of each table so selected).
|
|
</para>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Parameters</title>
|
|
|
|
<refsect2 id="SQL-WITH">
|
|
<title id="sql-with-title"><literal>WITH</literal> Clause</title>
|
|
|
|
<para>
|
|
The <literal>WITH</literal> clause allows you to specify one or more
|
|
subqueries that can be referenced by name in the primary query.
|
|
The subqueries effectively act as temporary tables or views
|
|
for the duration of the primary query.
|
|
Each subquery can be a <command>SELECT</command>, <command>TABLE</>, <command>VALUES</command>,
|
|
<command>INSERT</command>, <command>UPDATE</command> or
|
|
<command>DELETE</command> statement.
|
|
When writing a data-modifying statement (<command>INSERT</command>,
|
|
<command>UPDATE</command> or <command>DELETE</command>) in
|
|
<literal>WITH</>, it is usual to include a <literal>RETURNING</> clause.
|
|
It is the output of <literal>RETURNING</>, <emphasis>not</> the underlying
|
|
table that the statement modifies, that forms the temporary table that is
|
|
read by the primary query. If <literal>RETURNING</> is omitted, the
|
|
statement is still executed, but it produces no output so it cannot be
|
|
referenced as a table by the primary query.
|
|
</para>
|
|
|
|
<para>
|
|
A name (without schema qualification) must be specified for each
|
|
<literal>WITH</literal> query. Optionally, a list of column names
|
|
can be specified; if this is omitted,
|
|
the column names are inferred from the subquery.
|
|
</para>
|
|
|
|
<para>
|
|
If <literal>RECURSIVE</literal> is specified, it allows a
|
|
<command>SELECT</command> subquery to reference itself by name. Such a
|
|
subquery must have the form
|
|
<synopsis>
|
|
<replaceable class="parameter">non_recursive_term</replaceable> UNION [ ALL | DISTINCT ] <replaceable class="parameter">recursive_term</replaceable>
|
|
</synopsis>
|
|
where the recursive self-reference must appear on the right-hand
|
|
side of the <literal>UNION</>. Only one recursive self-reference
|
|
is permitted per query. Recursive data-modifying statements are not
|
|
supported, but you can use the results of a recursive
|
|
<command>SELECT</command> query in
|
|
a data-modifying statement. See <xref linkend="queries-with"> for
|
|
an example.
|
|
</para>
|
|
|
|
<para>
|
|
Another effect of <literal>RECURSIVE</literal> is that
|
|
<literal>WITH</literal> queries need not be ordered: a query
|
|
can reference another one that is later in the list. (However,
|
|
circular references, or mutual recursion, are not implemented.)
|
|
Without <literal>RECURSIVE</literal>, <literal>WITH</literal> queries
|
|
can only reference sibling <literal>WITH</literal> queries
|
|
that are earlier in the <literal>WITH</literal> list.
|
|
</para>
|
|
|
|
<para>
|
|
A key property of <literal>WITH</literal> queries is that they
|
|
are evaluated only once per execution of the primary query,
|
|
even if the primary query refers to them more than once.
|
|
In particular, data-modifying statements are guaranteed to be
|
|
executed once and only once, regardless of whether the primary query
|
|
reads all or any of their output.
|
|
</para>
|
|
|
|
<para>
|
|
The primary query and the <literal>WITH</literal> queries are all
|
|
(notionally) executed at the same time. This implies that the effects of
|
|
a data-modifying statement in <literal>WITH</literal> cannot be seen from
|
|
other parts of the query, other than by reading its <literal>RETURNING</>
|
|
output. If two such data-modifying statements attempt to modify the same
|
|
row, the results are unspecified.
|
|
</para>
|
|
|
|
<para>
|
|
See <xref linkend="queries-with"> for additional information.
|
|
</para>
|
|
</refsect2>
|
|
|
|
<refsect2 id="SQL-FROM">
|
|
<title id="sql-from-title"><literal>FROM</literal> Clause</title>
|
|
|
|
<para>
|
|
The <literal>FROM</literal> clause specifies one or more source
|
|
tables for the <command>SELECT</command>. If multiple sources are
|
|
specified, the result is the Cartesian product (cross join) of all
|
|
the sources. But usually qualification conditions are added (via
|
|
<literal>WHERE</>) to restrict the returned rows to a small subset of the
|
|
Cartesian product.
|
|
</para>
|
|
|
|
<para>
|
|
The <literal>FROM</literal> clause can contain the following
|
|
elements:
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><replaceable class="parameter">table_name</replaceable></term>
|
|
<listitem>
|
|
<para>
|
|
The name (optionally schema-qualified) of an existing table or view.
|
|
If <literal>ONLY</> is specified before the table name, only that
|
|
table is scanned. If <literal>ONLY</> is not specified, the table
|
|
and all its descendant tables (if any) are scanned. Optionally,
|
|
<literal>*</> can be specified after the table name to explicitly
|
|
indicate that descendant tables are included.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><replaceable class="parameter">alias</replaceable></term>
|
|
<listitem>
|
|
<para>
|
|
A substitute name for the <literal>FROM</> item containing the
|
|
alias. An alias is used for brevity or to eliminate ambiguity
|
|
for self-joins (where the same table is scanned multiple
|
|
times). When an alias is provided, it completely hides the
|
|
actual name of the table or function; for example given
|
|
<literal>FROM foo AS f</>, the remainder of the
|
|
<command>SELECT</command> must refer to this <literal>FROM</>
|
|
item as <literal>f</> not <literal>foo</>. If an alias is
|
|
written, a column alias list can also be written to provide
|
|
substitute names for one or more columns of the table.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><literal>TABLESAMPLE <replaceable class="parameter">sampling_method</replaceable> ( <replaceable class="parameter">argument</replaceable> [, ...] ) [ REPEATABLE ( <replaceable class="parameter">seed</replaceable> ) ]</literal></term>
|
|
<listitem>
|
|
<para>
|
|
A <literal>TABLESAMPLE</> clause after
|
|
a <replaceable class="parameter">table_name</> indicates that the
|
|
specified <replaceable class="parameter">sampling_method</replaceable>
|
|
should be used to retrieve a subset of the rows in that table.
|
|
This sampling precedes the application of any other filters such
|
|
as <literal>WHERE</> clauses.
|
|
The standard <productname>PostgreSQL</productname> distribution
|
|
includes two sampling methods, <literal>BERNOULLI</literal>
|
|
and <literal>SYSTEM</literal>, and other sampling methods can be
|
|
installed in the database via extensions.
|
|
</para>
|
|
|
|
<para>
|
|
The <literal>BERNOULLI</> and <literal>SYSTEM</> sampling methods
|
|
each accept a single <replaceable class="parameter">argument</>
|
|
which is the fraction of the table to sample, expressed as a
|
|
percentage between 0 and 100. This argument can be
|
|
any <type>real</>-valued expression. (Other sampling methods might
|
|
accept more or different arguments.) These two methods each return
|
|
a randomly-chosen sample of the table that will contain
|
|
approximately the specified percentage of the table's rows.
|
|
The <literal>BERNOULLI</literal> method scans the whole table and
|
|
selects or ignores individual rows independently with the specified
|
|
probability.
|
|
The <literal>SYSTEM</literal> method does block-level sampling with
|
|
each block having the specified chance of being selected; all rows
|
|
in each selected block are returned.
|
|
The <literal>SYSTEM</literal> method is significantly faster than
|
|
the <literal>BERNOULLI</literal> method when small sampling
|
|
percentages are specified, but it may return a less-random sample of
|
|
the table as a result of clustering effects.
|
|
</para>
|
|
|
|
<para>
|
|
The optional <literal>REPEATABLE</literal> clause specifies
|
|
a <replaceable class="parameter">seed</> number or expression to use
|
|
for generating random numbers within the sampling method. The seed
|
|
value can be any non-null floating-point value. Two queries that
|
|
specify the same seed and <replaceable class="parameter">argument</>
|
|
values will select the same sample of the table, if the table has
|
|
not been changed meanwhile. But different seed values will usually
|
|
produce different samples.
|
|
If <literal>REPEATABLE</literal> is not given then a new random
|
|
sample is selected for each query.
|
|
Note that some add-on sampling methods do not
|
|
accept <literal>REPEATABLE</literal>, and will always produce new
|
|
samples on each use.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><replaceable class="parameter">select</replaceable></term>
|
|
<listitem>
|
|
<para>
|
|
A sub-<command>SELECT</command> can appear in the
|
|
<literal>FROM</literal> clause. This acts as though its
|
|
output were created as a temporary table for the duration of
|
|
this single <command>SELECT</command> command. Note that the
|
|
sub-<command>SELECT</command> must be surrounded by
|
|
parentheses, and an alias <emphasis>must</emphasis> be
|
|
provided for it. A
|
|
<xref linkend="sql-values"> command
|
|
can also be used here.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><replaceable class="parameter">with_query_name</replaceable></term>
|
|
<listitem>
|
|
<para>
|
|
A <literal>WITH</> query is referenced by writing its name,
|
|
just as though the query's name were a table name. (In fact,
|
|
the <literal>WITH</> query hides any real table of the same name
|
|
for the purposes of the primary query. If necessary, you can
|
|
refer to a real table of the same name by schema-qualifying
|
|
the table's name.)
|
|
An alias can be provided in the same way as for a table.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><replaceable class="parameter">function_name</replaceable></term>
|
|
<listitem>
|
|
<para>
|
|
Function calls can appear in the <literal>FROM</literal>
|
|
clause. (This is especially useful for functions that return
|
|
result sets, but any function can be used.) This acts as
|
|
though the function's output were created as a temporary table for the
|
|
duration of this single <command>SELECT</command> command.
|
|
When the optional <command>WITH ORDINALITY</command> clause is
|
|
added to the function call, a new column is appended after
|
|
all the function's output columns with numbering for each row.
|
|
</para>
|
|
|
|
<para>
|
|
An alias can be provided in the same way as for a table.
|
|
If an alias is written, a column
|
|
alias list can also be written to provide substitute names for
|
|
one or more attributes of the function's composite return
|
|
type, including the column added by <literal>ORDINALITY</literal>
|
|
if present.
|
|
</para>
|
|
|
|
<para>
|
|
Multiple function calls can be combined into a
|
|
single <literal>FROM</>-clause item by surrounding them
|
|
with <literal>ROWS FROM( ... )</>. The output of such an item is the
|
|
concatenation of the first row from each function, then the second
|
|
row from each function, etc. If some of the functions produce fewer
|
|
rows than others, NULLs are substituted for the missing data, so
|
|
that the total number of rows returned is always the same as for the
|
|
function that produced the most rows.
|
|
</para>
|
|
|
|
<para>
|
|
If the function has been defined as returning the
|
|
<type>record</> data type, then an alias or the key word
|
|
<literal>AS</> must be present, followed by a column
|
|
definition list in the form <literal>( <replaceable
|
|
class="parameter">column_name</replaceable> <replaceable
|
|
class="parameter">data_type</replaceable> <optional>, ...
|
|
</>)</literal>. The column definition list must match the
|
|
actual number and types of columns returned by the function.
|
|
</para>
|
|
|
|
<para>
|
|
When using the <literal>ROWS FROM( ... )</> syntax, if one of the
|
|
functions requires a column definition list, it's preferred to put
|
|
the column definition list after the function call inside
|
|
<literal>ROWS FROM( ... )</>. A column definition list can be placed
|
|
after the <literal>ROWS FROM( ... )</> construct only if there's just
|
|
a single function and no <literal>WITH ORDINALITY</> clause.
|
|
</para>
|
|
|
|
<para>
|
|
To use <literal>ORDINALITY</literal> together with a column definition
|
|
list, you must use the <literal>ROWS FROM( ... )</> syntax and put the
|
|
column definition list inside <literal>ROWS FROM( ... )</>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><replaceable class="parameter">join_type</replaceable></term>
|
|
<listitem>
|
|
<para>
|
|
One of
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><literal>[ INNER ] JOIN</literal></para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><literal>LEFT [ OUTER ] JOIN</literal></para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><literal>RIGHT [ OUTER ] JOIN</literal></para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><literal>FULL [ OUTER ] JOIN</literal></para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><literal>CROSS JOIN</literal></para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
For the <literal>INNER</> and <literal>OUTER</> join types, a
|
|
join condition must be specified, namely exactly one of
|
|
<literal>NATURAL</>, <literal>ON <replaceable
|
|
class="parameter">join_condition</replaceable></literal>, or
|
|
<literal>USING (<replaceable
|
|
class="parameter">join_column</replaceable> [, ...])</literal>.
|
|
See below for the meaning. For <literal>CROSS JOIN</literal>,
|
|
none of these clauses can appear.
|
|
</para>
|
|
|
|
<para>
|
|
A <literal>JOIN</literal> clause combines two <literal>FROM</>
|
|
items, which for convenience we will refer to as <quote>tables</>,
|
|
though in reality they can be any type of <literal>FROM</> item.
|
|
Use parentheses if necessary to determine the order of nesting.
|
|
In the absence of parentheses, <literal>JOIN</literal>s nest
|
|
left-to-right. In any case <literal>JOIN</literal> binds more
|
|
tightly than the commas separating <literal>FROM</>-list items.
|
|
</para>
|
|
|
|
<para><literal>CROSS JOIN</> and <literal>INNER JOIN</literal>
|
|
produce a simple Cartesian product, the same result as you get from
|
|
listing the two tables at the top level of <literal>FROM</>,
|
|
but restricted by the join condition (if any).
|
|
<literal>CROSS JOIN</> is equivalent to <literal>INNER JOIN ON
|
|
(TRUE)</>, that is, no rows are removed by qualification.
|
|
These join types are just a notational convenience, since they
|
|
do nothing you couldn't do with plain <literal>FROM</> and
|
|
<literal>WHERE</>.
|
|
</para>
|
|
|
|
<para><literal>LEFT OUTER JOIN</> returns all rows in the qualified
|
|
Cartesian product (i.e., all combined rows that pass its join
|
|
condition), plus one copy of each row in the left-hand table
|
|
for which there was no right-hand row that passed the join
|
|
condition. This left-hand row is extended to the full width
|
|
of the joined table by inserting null values for the
|
|
right-hand columns. Note that only the <literal>JOIN</>
|
|
clause's own condition is considered while deciding which rows
|
|
have matches. Outer conditions are applied afterwards.
|
|
</para>
|
|
|
|
<para>
|
|
Conversely, <literal>RIGHT OUTER JOIN</> returns all the
|
|
joined rows, plus one row for each unmatched right-hand row
|
|
(extended with nulls on the left). This is just a notational
|
|
convenience, since you could convert it to a <literal>LEFT
|
|
OUTER JOIN</> by switching the left and right tables.
|
|
</para>
|
|
|
|
<para><literal>FULL OUTER JOIN</> returns all the joined rows, plus
|
|
one row for each unmatched left-hand row (extended with nulls
|
|
on the right), plus one row for each unmatched right-hand row
|
|
(extended with nulls on the left).
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><literal>ON <replaceable class="parameter">join_condition</replaceable></literal></term>
|
|
<listitem>
|
|
<para><replaceable class="parameter">join_condition</replaceable> is
|
|
an expression resulting in a value of type
|
|
<type>boolean</type> (similar to a <literal>WHERE</literal>
|
|
clause) that specifies which rows in a join are considered to
|
|
match.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><literal>USING ( <replaceable class="parameter">join_column</replaceable> [, ...] )</literal></term>
|
|
<listitem>
|
|
<para>
|
|
A clause of the form <literal>USING ( a, b, ... )</literal> is
|
|
shorthand for <literal>ON left_table.a = right_table.a AND
|
|
left_table.b = right_table.b ...</literal>. Also,
|
|
<literal>USING</> implies that only one of each pair of
|
|
equivalent columns will be included in the join output, not
|
|
both.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><literal>NATURAL</literal></term>
|
|
<listitem>
|
|
<para><literal>NATURAL</literal> is shorthand for a
|
|
<literal>USING</> list that mentions all columns in the two
|
|
tables that have the same names.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><literal>LATERAL</literal></term>
|
|
<listitem>
|
|
<para>
|
|
The <literal>LATERAL</literal> key word can precede a
|
|
sub-<command>SELECT</command> <literal>FROM</> item. This allows the
|
|
sub-<command>SELECT</command> to refer to columns of <literal>FROM</>
|
|
items that appear before it in the <literal>FROM</> list. (Without
|
|
<literal>LATERAL</literal>, each sub-<command>SELECT</command> is
|
|
evaluated independently and so cannot cross-reference any other
|
|
<literal>FROM</> item.)
|
|
</para>
|
|
|
|
<para><literal>LATERAL</literal> can also precede a function-call
|
|
<literal>FROM</> item, but in this case it is a noise word, because
|
|
the function expression can refer to earlier <literal>FROM</> items
|
|
in any case.
|
|
</para>
|
|
|
|
<para>
|
|
A <literal>LATERAL</literal> item can appear at top level in the
|
|
<literal>FROM</> list, or within a <literal>JOIN</> tree. In the
|
|
latter case it can also refer to any items that are on the left-hand
|
|
side of a <literal>JOIN</> that it is on the right-hand side of.
|
|
</para>
|
|
|
|
<para>
|
|
When a <literal>FROM</> item contains <literal>LATERAL</literal>
|
|
cross-references, evaluation proceeds as follows: for each row of the
|
|
<literal>FROM</> item providing the cross-referenced column(s), or
|
|
set of rows of multiple <literal>FROM</> items providing the
|
|
columns, the <literal>LATERAL</literal> item is evaluated using that
|
|
row or row set's values of the columns. The resulting row(s) are
|
|
joined as usual with the rows they were computed from. This is
|
|
repeated for each row or set of rows from the column source table(s).
|
|
</para>
|
|
|
|
<para>
|
|
The column source table(s) must be <literal>INNER</> or
|
|
<literal>LEFT</> joined to the <literal>LATERAL</literal> item, else
|
|
there would not be a well-defined set of rows from which to compute
|
|
each set of rows for the <literal>LATERAL</literal> item. Thus,
|
|
although a construct such as <literal><replaceable>X</> RIGHT JOIN
|
|
LATERAL <replaceable>Y</></literal> is syntactically valid, it is
|
|
not actually allowed for <replaceable>Y</> to reference
|
|
<replaceable>X</>.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</para>
|
|
</refsect2>
|
|
|
|
<refsect2 id="SQL-WHERE">
|
|
<title id="sql-where-title"><literal>WHERE</literal> Clause</title>
|
|
|
|
<para>
|
|
The optional <literal>WHERE</literal> clause has the general form
|
|
<synopsis>
|
|
WHERE <replaceable class="parameter">condition</replaceable>
|
|
</synopsis>
|
|
where <replaceable class="parameter">condition</replaceable> is
|
|
any expression that evaluates to a result of type
|
|
<type>boolean</type>. Any row that does not satisfy this
|
|
condition will be eliminated from the output. A row satisfies the
|
|
condition if it returns true when the actual row values are
|
|
substituted for any variable references.
|
|
</para>
|
|
</refsect2>
|
|
|
|
<refsect2 id="SQL-GROUPBY">
|
|
<title id="sql-groupby-title"><literal>GROUP BY</literal> Clause</title>
|
|
|
|
<para>
|
|
The optional <literal>GROUP BY</literal> clause has the general form
|
|
<synopsis>
|
|
GROUP BY <replaceable class="parameter">grouping_element</replaceable> [, ...]
|
|
</synopsis>
|
|
</para>
|
|
|
|
<para>
|
|
<literal>GROUP BY</literal> will condense into a single row all
|
|
selected rows that share the same values for the grouped
|
|
expressions. An <replaceable
|
|
class="parameter">expression</replaceable> used inside a
|
|
<replaceable class="parameter">grouping_element</replaceable>
|
|
can be an input column name, or the name or ordinal number of an
|
|
output column (<command>SELECT</command> list item), or an arbitrary
|
|
expression formed from input-column values. In case of ambiguity,
|
|
a <literal>GROUP BY</literal> name will be interpreted as an
|
|
input-column name rather than an output column name.
|
|
</para>
|
|
|
|
<para>
|
|
If any of <literal>GROUPING SETS</>, <literal>ROLLUP</> or
|
|
<literal>CUBE</> are present as grouping elements, then the
|
|
<literal>GROUP BY</> clause as a whole defines some number of
|
|
independent <replaceable>grouping sets</>. The effect of this is
|
|
equivalent to constructing a <literal>UNION ALL</> between
|
|
subqueries with the individual grouping sets as their
|
|
<literal>GROUP BY</> clauses. For further details on the handling
|
|
of grouping sets see <xref linkend="queries-grouping-sets">.
|
|
</para>
|
|
|
|
<para>
|
|
Aggregate functions, if any are used, are computed across all rows
|
|
making up each group, producing a separate value for each group.
|
|
(If there are aggregate functions but no <literal>GROUP BY</literal>
|
|
clause, the query is treated as having a single group comprising all
|
|
the selected rows.)
|
|
The set of rows fed to each aggregate function can be further filtered by
|
|
attaching a <literal>FILTER</literal> clause to the aggregate function
|
|
call; see <xref linkend="syntax-aggregates"> for more information. When
|
|
a <literal>FILTER</literal> clause is present, only those rows matching it
|
|
are included in the input to that aggregate function.
|
|
</para>
|
|
|
|
<para>
|
|
When <literal>GROUP BY</literal> is present,
|
|
or any aggregate functions are present, it is not valid for
|
|
the <command>SELECT</command> list expressions to refer to
|
|
ungrouped columns except within aggregate functions or when the
|
|
ungrouped column is functionally dependent on the grouped columns,
|
|
since there would otherwise be more than one possible value to
|
|
return for an ungrouped column. A functional dependency exists if
|
|
the grouped columns (or a subset thereof) are the primary key of
|
|
the table containing the ungrouped column.
|
|
</para>
|
|
|
|
<para>
|
|
Keep in mind that all aggregate functions are evaluated before
|
|
evaluating any <quote>scalar</> expressions in the <literal>HAVING</>
|
|
clause or <literal>SELECT</> list. This means that, for example,
|
|
a <literal>CASE</> expression cannot be used to skip evaluation of
|
|
an aggregate function; see <xref linkend="syntax-express-eval">.
|
|
</para>
|
|
|
|
<para>
|
|
Currently, <literal>FOR NO KEY UPDATE</>, <literal>FOR UPDATE</>,
|
|
<literal>FOR SHARE</> and <literal>FOR KEY SHARE</> cannot be
|
|
specified with <literal>GROUP BY</literal>.
|
|
</para>
|
|
</refsect2>
|
|
|
|
<refsect2 id="SQL-HAVING">
|
|
<title id="sql-having-title"><literal>HAVING</literal> Clause</title>
|
|
|
|
<para>
|
|
The optional <literal>HAVING</literal> clause has the general form
|
|
<synopsis>
|
|
HAVING <replaceable class="parameter">condition</replaceable>
|
|
</synopsis>
|
|
where <replaceable class="parameter">condition</replaceable> is
|
|
the same as specified for the <literal>WHERE</literal> clause.
|
|
</para>
|
|
|
|
<para>
|
|
<literal>HAVING</literal> eliminates group rows that do not
|
|
satisfy the condition. <literal>HAVING</literal> is different
|
|
from <literal>WHERE</literal>: <literal>WHERE</literal> filters
|
|
individual rows before the application of <literal>GROUP
|
|
BY</literal>, while <literal>HAVING</literal> filters group rows
|
|
created by <literal>GROUP BY</literal>. Each column referenced in
|
|
<replaceable class="parameter">condition</replaceable> must
|
|
unambiguously reference a grouping column, unless the reference
|
|
appears within an aggregate function or the ungrouped column is
|
|
functionally dependent on the grouping columns.
|
|
</para>
|
|
|
|
<para>
|
|
The presence of <literal>HAVING</literal> turns a query into a grouped
|
|
query even if there is no <literal>GROUP BY</> clause. This is the
|
|
same as what happens when the query contains aggregate functions but
|
|
no <literal>GROUP BY</> clause. All the selected rows are considered to
|
|
form a single group, and the <command>SELECT</command> list and
|
|
<literal>HAVING</literal> clause can only reference table columns from
|
|
within aggregate functions. Such a query will emit a single row if the
|
|
<literal>HAVING</literal> condition is true, zero rows if it is not true.
|
|
</para>
|
|
|
|
<para>
|
|
Currently, <literal>FOR NO KEY UPDATE</>, <literal>FOR UPDATE</>,
|
|
<literal>FOR SHARE</> and <literal>FOR KEY SHARE</> cannot be
|
|
specified with <literal>HAVING</literal>.
|
|
</para>
|
|
</refsect2>
|
|
|
|
<refsect2 id="SQL-WINDOW">
|
|
<title id="sql-window-title"><literal>WINDOW</literal> Clause</title>
|
|
|
|
<para>
|
|
The optional <literal>WINDOW</literal> clause has the general form
|
|
<synopsis>
|
|
WINDOW <replaceable class="parameter">window_name</replaceable> AS ( <replaceable class="parameter">window_definition</replaceable> ) [, ...]
|
|
</synopsis>
|
|
where <replaceable class="parameter">window_name</replaceable> is
|
|
a name that can be referenced from <literal>OVER</> clauses or
|
|
subsequent window definitions, and
|
|
<replaceable class="parameter">window_definition</replaceable> is
|
|
<synopsis>
|
|
[ <replaceable class="parameter">existing_window_name</replaceable> ]
|
|
[ PARTITION BY <replaceable class="parameter">expression</replaceable> [, ...] ]
|
|
[ ORDER BY <replaceable class="parameter">expression</replaceable> [ ASC | DESC | USING <replaceable class="parameter">operator</replaceable> ] [ NULLS { FIRST | LAST } ] [, ...] ]
|
|
[ <replaceable class="parameter">frame_clause</replaceable> ]
|
|
</synopsis>
|
|
</para>
|
|
|
|
<para>
|
|
If an <replaceable class="parameter">existing_window_name</replaceable>
|
|
is specified it must refer to an earlier entry in the <literal>WINDOW</>
|
|
list; the new window copies its partitioning clause from that entry,
|
|
as well as its ordering clause if any. In this case the new window cannot
|
|
specify its own <literal>PARTITION BY</> clause, and it can specify
|
|
<literal>ORDER BY</> only if the copied window does not have one.
|
|
The new window always uses its own frame clause; the copied window
|
|
must not specify a frame clause.
|
|
</para>
|
|
|
|
<para>
|
|
The elements of the <literal>PARTITION BY</> list are interpreted in
|
|
much the same fashion as elements of a
|
|
<xref linkend="sql-groupby" endterm="sql-groupby-title">, except that
|
|
they are always simple expressions and never the name or number of an
|
|
output column.
|
|
Another difference is that these expressions can contain aggregate
|
|
function calls, which are not allowed in a regular <literal>GROUP BY</>
|
|
clause. They are allowed here because windowing occurs after grouping
|
|
and aggregation.
|
|
</para>
|
|
|
|
<para>
|
|
Similarly, the elements of the <literal>ORDER BY</> list are interpreted
|
|
in much the same fashion as elements of an
|
|
<xref linkend="sql-orderby" endterm="sql-orderby-title">, except that
|
|
the expressions are always taken as simple expressions and never the name
|
|
or number of an output column.
|
|
</para>
|
|
|
|
<para>
|
|
The optional <replaceable class="parameter">frame_clause</> defines
|
|
the <firstterm>window frame</> for window functions that depend on the
|
|
frame (not all do). The window frame is a set of related rows for
|
|
each row of the query (called the <firstterm>current row</>).
|
|
The <replaceable class="parameter">frame_clause</> can be one of
|
|
|
|
<synopsis>
|
|
{ RANGE | ROWS } <replaceable>frame_start</>
|
|
{ RANGE | ROWS } BETWEEN <replaceable>frame_start</> AND <replaceable>frame_end</>
|
|
</synopsis>
|
|
|
|
where <replaceable>frame_start</> and <replaceable>frame_end</> can be
|
|
one of
|
|
|
|
<synopsis>
|
|
UNBOUNDED PRECEDING
|
|
<replaceable>value</replaceable> PRECEDING
|
|
CURRENT ROW
|
|
<replaceable>value</replaceable> FOLLOWING
|
|
UNBOUNDED FOLLOWING
|
|
</synopsis>
|
|
|
|
If <replaceable>frame_end</> is omitted it defaults to <literal>CURRENT
|
|
ROW</>. Restrictions are that
|
|
<replaceable>frame_start</> cannot be <literal>UNBOUNDED FOLLOWING</>,
|
|
<replaceable>frame_end</> cannot be <literal>UNBOUNDED PRECEDING</>,
|
|
and the <replaceable>frame_end</> choice cannot appear earlier in the
|
|
above list than the <replaceable>frame_start</> choice — for example
|
|
<literal>RANGE BETWEEN CURRENT ROW AND <replaceable>value</>
|
|
PRECEDING</literal> is not allowed.
|
|
</para>
|
|
|
|
<para>
|
|
The default framing option is <literal>RANGE UNBOUNDED PRECEDING</>,
|
|
which is the same as <literal>RANGE BETWEEN UNBOUNDED PRECEDING AND
|
|
CURRENT ROW</>; it sets the frame to be all rows from the partition start
|
|
up through the current row's last peer (a row that <literal>ORDER
|
|
BY</> considers equivalent to the current row, or all rows if there
|
|
is no <literal>ORDER BY</>).
|
|
In general, <literal>UNBOUNDED PRECEDING</> means that the frame
|
|
starts with the first row of the partition, and similarly
|
|
<literal>UNBOUNDED FOLLOWING</> means that the frame ends with the last
|
|
row of the partition (regardless of <literal>RANGE</> or <literal>ROWS</>
|
|
mode). In <literal>ROWS</> mode, <literal>CURRENT ROW</>
|
|
means that the frame starts or ends with the current row; but in
|
|
<literal>RANGE</> mode it means that the frame starts or ends with
|
|
the current row's first or last peer in the <literal>ORDER BY</> ordering.
|
|
The <replaceable>value</> <literal>PRECEDING</> and
|
|
<replaceable>value</> <literal>FOLLOWING</> cases are currently only
|
|
allowed in <literal>ROWS</> mode. They indicate that the frame starts
|
|
or ends with the row that many rows before or after the current row.
|
|
<replaceable>value</replaceable> must be an integer expression not
|
|
containing any variables, aggregate functions, or window functions.
|
|
The value must not be null or negative; but it can be zero, which
|
|
selects the current row itself.
|
|
</para>
|
|
|
|
<para>
|
|
Beware that the <literal>ROWS</> options can produce unpredictable
|
|
results if the <literal>ORDER BY</> ordering does not order the rows
|
|
uniquely. The <literal>RANGE</> options are designed to ensure that
|
|
rows that are peers in the <literal>ORDER BY</> ordering are treated
|
|
alike; all peer rows will be in the same frame.
|
|
</para>
|
|
|
|
<para>
|
|
The purpose of a <literal>WINDOW</literal> clause is to specify the
|
|
behavior of <firstterm>window functions</> appearing in the query's
|
|
<xref linkend="sql-select-list" endterm="sql-select-list-title"> or
|
|
<xref linkend="sql-orderby" endterm="sql-orderby-title">. These functions
|
|
can reference the <literal>WINDOW</literal> clause entries by name
|
|
in their <literal>OVER</> clauses. A <literal>WINDOW</literal> clause
|
|
entry does not have to be referenced anywhere, however; if it is not
|
|
used in the query it is simply ignored. It is possible to use window
|
|
functions without any <literal>WINDOW</literal> clause at all, since
|
|
a window function call can specify its window definition directly in
|
|
its <literal>OVER</> clause. However, the <literal>WINDOW</literal>
|
|
clause saves typing when the same window definition is needed for more
|
|
than one window function.
|
|
</para>
|
|
|
|
<para>
|
|
Currently, <literal>FOR NO KEY UPDATE</>, <literal>FOR UPDATE</>,
|
|
<literal>FOR SHARE</> and <literal>FOR KEY SHARE</> cannot be
|
|
specified with <literal>WINDOW</literal>.
|
|
</para>
|
|
|
|
<para>
|
|
Window functions are described in detail in
|
|
<xref linkend="tutorial-window">,
|
|
<xref linkend="syntax-window-functions">, and
|
|
<xref linkend="queries-window">.
|
|
</para>
|
|
</refsect2>
|
|
|
|
<refsect2 id="sql-select-list">
|
|
<title id="sql-select-list-title"><command>SELECT</command> List</title>
|
|
|
|
<para>
|
|
The <command>SELECT</command> list (between the key words
|
|
<literal>SELECT</> and <literal>FROM</>) specifies expressions
|
|
that form the output rows of the <command>SELECT</command>
|
|
statement. The expressions can (and usually do) refer to columns
|
|
computed in the <literal>FROM</> clause.
|
|
</para>
|
|
|
|
<para>
|
|
Just as in a table, every output column of a <command>SELECT</command>
|
|
has a name. In a simple <command>SELECT</command> this name is just
|
|
used to label the column for display, but when the <command>SELECT</>
|
|
is a sub-query of a larger query, the name is seen by the larger query
|
|
as the column name of the virtual table produced by the sub-query.
|
|
To specify the name to use for an output column, write
|
|
<literal>AS</> <replaceable class="parameter">output_name</replaceable>
|
|
after the column's expression. (You can omit <literal>AS</literal>,
|
|
but only if the desired output name does not match any
|
|
<productname>PostgreSQL</productname> keyword (see <xref
|
|
linkend="sql-keywords-appendix">). For protection against possible
|
|
future keyword additions, it is recommended that you always either
|
|
write <literal>AS</literal> or double-quote the output name.)
|
|
If you do not specify a column name, a name is chosen automatically
|
|
by <productname>PostgreSQL</productname>. If the column's expression
|
|
is a simple column reference then the chosen name is the same as that
|
|
column's name. In more complex cases a function or type name may be
|
|
used, or the system may fall back on a generated name such as
|
|
<literal>?column?</literal>.
|
|
</para>
|
|
|
|
<para>
|
|
An output column's name can be used to refer to the column's value in
|
|
<literal>ORDER BY</> and <literal>GROUP BY</> clauses, but not in the
|
|
<literal>WHERE</> or <literal>HAVING</> clauses; there you must write
|
|
out the expression instead.
|
|
</para>
|
|
|
|
<para>
|
|
Instead of an expression, <literal>*</literal> can be written in
|
|
the output list as a shorthand for all the columns of the selected
|
|
rows. Also, you can write <literal><replaceable
|
|
class="parameter">table_name</replaceable>.*</literal> as a
|
|
shorthand for the columns coming from just that table. In these
|
|
cases it is not possible to specify new names with <literal>AS</>;
|
|
the output column names will be the same as the table columns' names.
|
|
</para>
|
|
</refsect2>
|
|
|
|
<refsect2 id="sql-distinct">
|
|
<title id="sql-distinct-title"><literal>DISTINCT</literal> Clause</title>
|
|
|
|
<para>
|
|
If <literal>SELECT DISTINCT</> is specified, all duplicate rows are
|
|
removed from the result set (one row is kept from each group of
|
|
duplicates). <literal>SELECT ALL</> specifies the opposite: all rows are
|
|
kept; that is the default.
|
|
</para>
|
|
|
|
<para>
|
|
<literal>SELECT DISTINCT ON ( <replaceable
|
|
class="parameter">expression</replaceable> [, ...] )</literal>
|
|
keeps only the first row of each set of rows where the given
|
|
expressions evaluate to equal. The <literal>DISTINCT ON</literal>
|
|
expressions are interpreted using the same rules as for
|
|
<literal>ORDER BY</> (see above). Note that the <quote>first
|
|
row</quote> of each set is unpredictable unless <literal>ORDER
|
|
BY</> is used to ensure that the desired row appears first. For
|
|
example:
|
|
<programlisting>
|
|
SELECT DISTINCT ON (location) location, time, report
|
|
FROM weather_reports
|
|
ORDER BY location, time DESC;
|
|
</programlisting>
|
|
retrieves the most recent weather report for each location. But
|
|
if we had not used <literal>ORDER BY</> to force descending order
|
|
of time values for each location, we'd have gotten a report from
|
|
an unpredictable time for each location.
|
|
</para>
|
|
|
|
<para>
|
|
The <literal>DISTINCT ON</> expression(s) must match the leftmost
|
|
<literal>ORDER BY</> expression(s). The <literal>ORDER BY</> clause
|
|
will normally contain additional expression(s) that determine the
|
|
desired precedence of rows within each <literal>DISTINCT ON</> group.
|
|
</para>
|
|
|
|
<para>
|
|
Currently, <literal>FOR NO KEY UPDATE</>, <literal>FOR UPDATE</>,
|
|
<literal>FOR SHARE</> and <literal>FOR KEY SHARE</> cannot be
|
|
specified with <literal>DISTINCT</literal>.
|
|
</para>
|
|
</refsect2>
|
|
|
|
<refsect2 id="SQL-UNION">
|
|
<title id="sql-union-title"><literal>UNION</literal> Clause</title>
|
|
|
|
<para>
|
|
The <literal>UNION</literal> clause has this general form:
|
|
<synopsis>
|
|
<replaceable class="parameter">select_statement</replaceable> UNION [ ALL | DISTINCT ] <replaceable class="parameter">select_statement</replaceable>
|
|
</synopsis><replaceable class="parameter">select_statement</replaceable> is
|
|
any <command>SELECT</command> statement without an <literal>ORDER
|
|
BY</>, <literal>LIMIT</>, <literal>FOR NO KEY UPDATE</>, <literal>FOR UPDATE</literal>,
|
|
<literal>FOR SHARE</literal>, or <literal>FOR KEY SHARE</literal> clause.
|
|
(<literal>ORDER BY</> and <literal>LIMIT</> can be attached to a
|
|
subexpression if it is enclosed in parentheses. Without
|
|
parentheses, these clauses will be taken to apply to the result of
|
|
the <literal>UNION</literal>, not to its right-hand input
|
|
expression.)
|
|
</para>
|
|
|
|
<para>
|
|
The <literal>UNION</literal> operator computes the set union of
|
|
the rows returned by the involved <command>SELECT</command>
|
|
statements. A row is in the set union of two result sets if it
|
|
appears in at least one of the result sets. The two
|
|
<command>SELECT</command> statements that represent the direct
|
|
operands of the <literal>UNION</literal> must produce the same
|
|
number of columns, and corresponding columns must be of compatible
|
|
data types.
|
|
</para>
|
|
|
|
<para>
|
|
The result of <literal>UNION</> does not contain any duplicate
|
|
rows unless the <literal>ALL</> option is specified.
|
|
<literal>ALL</> prevents elimination of duplicates. (Therefore,
|
|
<literal>UNION ALL</> is usually significantly quicker than
|
|
<literal>UNION</>; use <literal>ALL</> when you can.)
|
|
<literal>DISTINCT</> can be written to explicitly specify the
|
|
default behavior of eliminating duplicate rows.
|
|
</para>
|
|
|
|
<para>
|
|
Multiple <literal>UNION</> operators in the same
|
|
<command>SELECT</command> statement are evaluated left to right,
|
|
unless otherwise indicated by parentheses.
|
|
</para>
|
|
|
|
<para>
|
|
Currently, <literal>FOR NO KEY UPDATE</>, <literal>FOR UPDATE</>, <literal>FOR SHARE</> and
|
|
<literal>FOR KEY SHARE</> cannot be
|
|
specified either for a <literal>UNION</> result or for any input of a
|
|
<literal>UNION</>.
|
|
</para>
|
|
</refsect2>
|
|
|
|
<refsect2 id="SQL-INTERSECT">
|
|
<title id="sql-intersect-title"><literal>INTERSECT</literal> Clause</title>
|
|
|
|
<para>
|
|
The <literal>INTERSECT</literal> clause has this general form:
|
|
<synopsis>
|
|
<replaceable class="parameter">select_statement</replaceable> INTERSECT [ ALL | DISTINCT ] <replaceable class="parameter">select_statement</replaceable>
|
|
</synopsis><replaceable class="parameter">select_statement</replaceable> is
|
|
any <command>SELECT</command> statement without an <literal>ORDER
|
|
BY</>, <literal>LIMIT</>, <literal>FOR NO KEY UPDATE</>, <literal>FOR UPDATE</literal>,
|
|
<literal>FOR SHARE</literal>, or <literal>FOR KEY SHARE</> clause.
|
|
</para>
|
|
|
|
<para>
|
|
The <literal>INTERSECT</literal> operator computes the set
|
|
intersection of the rows returned by the involved
|
|
<command>SELECT</command> statements. A row is in the
|
|
intersection of two result sets if it appears in both result sets.
|
|
</para>
|
|
|
|
<para>
|
|
The result of <literal>INTERSECT</literal> does not contain any
|
|
duplicate rows unless the <literal>ALL</> option is specified.
|
|
With <literal>ALL</>, a row that has <replaceable>m</> duplicates in the
|
|
left table and <replaceable>n</> duplicates in the right table will appear
|
|
min(<replaceable>m</>,<replaceable>n</>) times in the result set.
|
|
<literal>DISTINCT</> can be written to explicitly specify the
|
|
default behavior of eliminating duplicate rows.
|
|
</para>
|
|
|
|
<para>
|
|
Multiple <literal>INTERSECT</literal> operators in the same
|
|
<command>SELECT</command> statement are evaluated left to right,
|
|
unless parentheses dictate otherwise.
|
|
<literal>INTERSECT</literal> binds more tightly than
|
|
<literal>UNION</literal>. That is, <literal>A UNION B INTERSECT
|
|
C</literal> will be read as <literal>A UNION (B INTERSECT
|
|
C)</literal>.
|
|
</para>
|
|
|
|
<para>
|
|
Currently, <literal>FOR NO KEY UPDATE</>, <literal>FOR UPDATE</>, <literal>FOR SHARE</> and
|
|
<literal>FOR KEY SHARE</> cannot be
|
|
specified either for an <literal>INTERSECT</> result or for any input of
|
|
an <literal>INTERSECT</>.
|
|
</para>
|
|
</refsect2>
|
|
|
|
<refsect2 id="SQL-EXCEPT">
|
|
<title id="sql-except-title"><literal>EXCEPT</literal> Clause</title>
|
|
|
|
<para>
|
|
The <literal>EXCEPT</literal> clause has this general form:
|
|
<synopsis>
|
|
<replaceable class="parameter">select_statement</replaceable> EXCEPT [ ALL | DISTINCT ] <replaceable class="parameter">select_statement</replaceable>
|
|
</synopsis><replaceable class="parameter">select_statement</replaceable> is
|
|
any <command>SELECT</command> statement without an <literal>ORDER
|
|
BY</>, <literal>LIMIT</>, <literal>FOR NO KEY UPDATE</>, <literal>FOR UPDATE</literal>,
|
|
<literal>FOR SHARE</literal>, or <literal>FOR KEY SHARE</> clause.
|
|
</para>
|
|
|
|
<para>
|
|
The <literal>EXCEPT</literal> operator computes the set of rows
|
|
that are in the result of the left <command>SELECT</command>
|
|
statement but not in the result of the right one.
|
|
</para>
|
|
|
|
<para>
|
|
The result of <literal>EXCEPT</literal> does not contain any
|
|
duplicate rows unless the <literal>ALL</> option is specified.
|
|
With <literal>ALL</>, a row that has <replaceable>m</> duplicates in the
|
|
left table and <replaceable>n</> duplicates in the right table will appear
|
|
max(<replaceable>m</>-<replaceable>n</>,0) times in the result set.
|
|
<literal>DISTINCT</> can be written to explicitly specify the
|
|
default behavior of eliminating duplicate rows.
|
|
</para>
|
|
|
|
<para>
|
|
Multiple <literal>EXCEPT</literal> operators in the same
|
|
<command>SELECT</command> statement are evaluated left to right,
|
|
unless parentheses dictate otherwise. <literal>EXCEPT</> binds at
|
|
the same level as <literal>UNION</>.
|
|
</para>
|
|
|
|
<para>
|
|
Currently, <literal>FOR NO KEY UPDATE</>, <literal>FOR UPDATE</>, <literal>FOR SHARE</> and
|
|
<literal>FOR KEY SHARE</> cannot be
|
|
specified either for an <literal>EXCEPT</> result or for any input of
|
|
an <literal>EXCEPT</>.
|
|
</para>
|
|
</refsect2>
|
|
|
|
<refsect2 id="SQL-ORDERBY">
|
|
<title id="sql-orderby-title"><literal>ORDER BY</literal> Clause</title>
|
|
|
|
<para>
|
|
The optional <literal>ORDER BY</literal> clause has this general form:
|
|
<synopsis>
|
|
ORDER BY <replaceable class="parameter">expression</replaceable> [ ASC | DESC | USING <replaceable class="parameter">operator</replaceable> ] [ NULLS { FIRST | LAST } ] [, ...]
|
|
</synopsis>
|
|
The <literal>ORDER BY</literal> clause causes the result rows to
|
|
be sorted according to the specified expression(s). If two rows are
|
|
equal according to the leftmost expression, they are compared
|
|
according to the next expression and so on. If they are equal
|
|
according to all specified expressions, they are returned in
|
|
an implementation-dependent order.
|
|
</para>
|
|
|
|
<para>
|
|
Each <replaceable class="parameter">expression</replaceable> can be the
|
|
name or ordinal number of an output column
|
|
(<command>SELECT</command> list item), or it can be an arbitrary
|
|
expression formed from input-column values.
|
|
</para>
|
|
|
|
<para>
|
|
The ordinal number refers to the ordinal (left-to-right) position
|
|
of the output column. This feature makes it possible to define an
|
|
ordering on the basis of a column that does not have a unique
|
|
name. This is never absolutely necessary because it is always
|
|
possible to assign a name to an output column using the
|
|
<literal>AS</> clause.
|
|
</para>
|
|
|
|
<para>
|
|
It is also possible to use arbitrary expressions in the
|
|
<literal>ORDER BY</literal> clause, including columns that do not
|
|
appear in the <command>SELECT</command> output list. Thus the
|
|
following statement is valid:
|
|
<programlisting>
|
|
SELECT name FROM distributors ORDER BY code;
|
|
</programlisting>
|
|
A limitation of this feature is that an <literal>ORDER BY</>
|
|
clause applying to the result of a <literal>UNION</>,
|
|
<literal>INTERSECT</>, or <literal>EXCEPT</> clause can only
|
|
specify an output column name or number, not an expression.
|
|
</para>
|
|
|
|
<para>
|
|
If an <literal>ORDER BY</> expression is a simple name that
|
|
matches both an output column name and an input column name,
|
|
<literal>ORDER BY</> will interpret it as the output column name.
|
|
This is the opposite of the choice that <literal>GROUP BY</> will
|
|
make in the same situation. This inconsistency is made to be
|
|
compatible with the SQL standard.
|
|
</para>
|
|
|
|
<para>
|
|
Optionally one can add the key word <literal>ASC</> (ascending) or
|
|
<literal>DESC</> (descending) after any expression in the
|
|
<literal>ORDER BY</> clause. If not specified, <literal>ASC</> is
|
|
assumed by default. Alternatively, a specific ordering operator
|
|
name can be specified in the <literal>USING</> clause.
|
|
An ordering operator must be a less-than or greater-than
|
|
member of some B-tree operator family.
|
|
<literal>ASC</> is usually equivalent to <literal>USING <</> and
|
|
<literal>DESC</> is usually equivalent to <literal>USING ></>.
|
|
(But the creator of a user-defined data type can define exactly what the
|
|
default sort ordering is, and it might correspond to operators with other
|
|
names.)
|
|
</para>
|
|
|
|
<para>
|
|
If <literal>NULLS LAST</> is specified, null values sort after all
|
|
non-null values; if <literal>NULLS FIRST</> is specified, null values
|
|
sort before all non-null values. If neither is specified, the default
|
|
behavior is <literal>NULLS LAST</> when <literal>ASC</> is specified
|
|
or implied, and <literal>NULLS FIRST</> when <literal>DESC</> is specified
|
|
(thus, the default is to act as though nulls are larger than non-nulls).
|
|
When <literal>USING</> is specified, the default nulls ordering depends
|
|
on whether the operator is a less-than or greater-than operator.
|
|
</para>
|
|
|
|
<para>
|
|
Note that ordering options apply only to the expression they follow;
|
|
for example <literal>ORDER BY x, y DESC</> does not mean
|
|
the same thing as <literal>ORDER BY x DESC, y DESC</>.
|
|
</para>
|
|
|
|
<para>
|
|
Character-string data is sorted according to the collation that applies
|
|
to the column being sorted. That can be overridden at need by including
|
|
a <literal>COLLATE</> clause in the
|
|
<replaceable class="parameter">expression</replaceable>, for example
|
|
<literal>ORDER BY mycolumn COLLATE "en_US"</>.
|
|
For more information see <xref linkend="sql-syntax-collate-exprs"> and
|
|
<xref linkend="collation">.
|
|
</para>
|
|
</refsect2>
|
|
|
|
<refsect2 id="SQL-LIMIT">
|
|
<title id="sql-limit-title"><literal>LIMIT</literal> Clause</title>
|
|
|
|
<para>
|
|
The <literal>LIMIT</literal> clause consists of two independent
|
|
sub-clauses:
|
|
<synopsis>
|
|
LIMIT { <replaceable class="parameter">count</replaceable> | ALL }
|
|
OFFSET <replaceable class="parameter">start</replaceable>
|
|
</synopsis>
|
|
<replaceable class="parameter">count</replaceable> specifies the
|
|
maximum number of rows to return, while <replaceable
|
|
class="parameter">start</replaceable> specifies the number of rows
|
|
to skip before starting to return rows. When both are specified,
|
|
<replaceable class="parameter">start</replaceable> rows are skipped
|
|
before starting to count the <replaceable
|
|
class="parameter">count</replaceable> rows to be returned.
|
|
</para>
|
|
|
|
<para>
|
|
If the <replaceable class="parameter">count</replaceable> expression
|
|
evaluates to NULL, it is treated as <literal>LIMIT ALL</>, i.e., no
|
|
limit. If <replaceable class="parameter">start</replaceable> evaluates
|
|
to NULL, it is treated the same as <literal>OFFSET 0</>.
|
|
</para>
|
|
|
|
<para>
|
|
SQL:2008 introduced a different syntax to achieve the same result,
|
|
which <productname>PostgreSQL</> also supports. It is:
|
|
<synopsis>
|
|
OFFSET <replaceable class="parameter">start</replaceable> { ROW | ROWS }
|
|
FETCH { FIRST | NEXT } [ <replaceable class="parameter">count</replaceable> ] { ROW | ROWS } ONLY
|
|
</synopsis>
|
|
In this syntax, to write anything except a simple integer constant for
|
|
<replaceable class="parameter">start</> or <replaceable
|
|
class="parameter">count</replaceable>, you must write parentheses
|
|
around it.
|
|
If <replaceable class="parameter">count</> is
|
|
omitted in a <literal>FETCH</> clause, it defaults to 1.
|
|
<literal>ROW</literal>
|
|
and <literal>ROWS</literal> as well as <literal>FIRST</literal>
|
|
and <literal>NEXT</literal> are noise words that don't influence
|
|
the effects of these clauses.
|
|
According to the standard, the <literal>OFFSET</literal> clause must come
|
|
before the <literal>FETCH</literal> clause if both are present; but
|
|
<productname>PostgreSQL</> is laxer and allows either order.
|
|
</para>
|
|
|
|
<para>
|
|
When using <literal>LIMIT</>, it is a good idea to use an
|
|
<literal>ORDER BY</> clause that constrains the result rows into a
|
|
unique order. Otherwise you will get an unpredictable subset of
|
|
the query's rows — you might be asking for the tenth through
|
|
twentieth rows, but tenth through twentieth in what ordering? You
|
|
don't know what ordering unless you specify <literal>ORDER BY</>.
|
|
</para>
|
|
|
|
<para>
|
|
The query planner takes <literal>LIMIT</> into account when
|
|
generating a query plan, so you are very likely to get different
|
|
plans (yielding different row orders) depending on what you use
|
|
for <literal>LIMIT</> and <literal>OFFSET</>. Thus, using
|
|
different <literal>LIMIT</>/<literal>OFFSET</> values to select
|
|
different subsets of a query result <emphasis>will give
|
|
inconsistent results</emphasis> unless you enforce a predictable
|
|
result ordering with <literal>ORDER BY</>. This is not a bug; it
|
|
is an inherent consequence of the fact that SQL does not promise
|
|
to deliver the results of a query in any particular order unless
|
|
<literal>ORDER BY</> is used to constrain the order.
|
|
</para>
|
|
|
|
<para>
|
|
It is even possible for repeated executions of the same <literal>LIMIT</>
|
|
query to return different subsets of the rows of a table, if there
|
|
is not an <literal>ORDER BY</> to enforce selection of a deterministic
|
|
subset. Again, this is not a bug; determinism of the results is
|
|
simply not guaranteed in such a case.
|
|
</para>
|
|
</refsect2>
|
|
|
|
<refsect2 id="SQL-FOR-UPDATE-SHARE">
|
|
<title id="sql-for-update-share-title">The Locking Clause</title>
|
|
|
|
<para>
|
|
<literal>FOR UPDATE</>, <literal>FOR NO KEY UPDATE</>, <literal>FOR SHARE</>
|
|
and <literal>FOR KEY SHARE</>
|
|
are <firstterm>locking clauses</>; they affect how <literal>SELECT</>
|
|
locks rows as they are obtained from the table.
|
|
</para>
|
|
|
|
<para>
|
|
The locking clause has the general form
|
|
|
|
<synopsis>
|
|
FOR <replaceable>lock_strength</> [ OF <replaceable class="parameter">table_name</replaceable> [, ...] ] [ NOWAIT | SKIP LOCKED ]
|
|
</synopsis>
|
|
|
|
where <replaceable>lock_strength</> can be one of
|
|
|
|
<synopsis>
|
|
UPDATE
|
|
NO KEY UPDATE
|
|
SHARE
|
|
KEY SHARE
|
|
</synopsis>
|
|
</para>
|
|
|
|
<para>
|
|
For more information on each row-level lock mode, refer to
|
|
<xref linkend="locking-rows">.
|
|
</para>
|
|
|
|
<para>
|
|
To prevent the operation from waiting for other transactions to commit,
|
|
use either the <literal>NOWAIT</> or <literal>SKIP LOCKED</literal>
|
|
option. With <literal>NOWAIT</>, the statement reports an error, rather
|
|
than waiting, if a selected row cannot be locked immediately.
|
|
With <literal>SKIP LOCKED</literal>, any selected rows that cannot be
|
|
immediately locked are skipped. Skipping locked rows provides an
|
|
inconsistent view of the data, so this is not suitable for general purpose
|
|
work, but can be used to avoid lock contention with multiple consumers
|
|
accessing a queue-like table.
|
|
Note that <literal>NOWAIT</> and <literal>SKIP LOCKED</literal> apply only
|
|
to the row-level lock(s) — the required <literal>ROW SHARE</literal>
|
|
table-level lock is still taken in the ordinary way (see
|
|
<xref linkend="mvcc">). You can use
|
|
<xref linkend="sql-lock">
|
|
with the <literal>NOWAIT</> option first,
|
|
if you need to acquire the table-level lock without waiting.
|
|
</para>
|
|
|
|
<para>
|
|
If specific tables are named in a locking clause,
|
|
then only rows coming from those tables are locked; any other
|
|
tables used in the <command>SELECT</command> are simply read as
|
|
usual. A locking
|
|
clause without a table list affects all tables used in the statement.
|
|
If a locking clause is
|
|
applied to a view or sub-query, it affects all tables used in
|
|
the view or sub-query.
|
|
However, these clauses
|
|
do not apply to <literal>WITH</> queries referenced by the primary query.
|
|
If you want row locking to occur within a <literal>WITH</> query, specify
|
|
a locking clause within the <literal>WITH</> query.
|
|
</para>
|
|
|
|
<para>
|
|
Multiple locking
|
|
clauses can be written if it is necessary to specify different locking
|
|
behavior for different tables. If the same table is mentioned (or
|
|
implicitly affected) by more than one locking clause,
|
|
then it is processed as if it was only specified by the strongest one.
|
|
Similarly, a table is processed
|
|
as <literal>NOWAIT</> if that is specified in any of the clauses
|
|
affecting it. Otherwise, it is processed
|
|
as <literal>SKIP LOCKED</literal> if that is specified in any of the
|
|
clauses affecting it.
|
|
</para>
|
|
|
|
<para>
|
|
The locking clauses cannot be
|
|
used in contexts where returned rows cannot be clearly identified with
|
|
individual table rows; for example they cannot be used with aggregation.
|
|
</para>
|
|
|
|
<para>
|
|
When a locking clause
|
|
appears at the top level of a <command>SELECT</> query, the rows that
|
|
are locked are exactly those that are returned by the query; in the
|
|
case of a join query, the rows locked are those that contribute to
|
|
returned join rows. In addition, rows that satisfied the query
|
|
conditions as of the query snapshot will be locked, although they
|
|
will not be returned if they were updated after the snapshot
|
|
and no longer satisfy the query conditions. If a
|
|
<literal>LIMIT</> is used, locking stops
|
|
once enough rows have been returned to satisfy the limit (but note that
|
|
rows skipped over by <literal>OFFSET</> will get locked). Similarly,
|
|
if a locking clause
|
|
is used in a cursor's query, only rows actually fetched or stepped past
|
|
by the cursor will be locked.
|
|
</para>
|
|
|
|
<para>
|
|
When a locking clause
|
|
appears in a sub-<command>SELECT</>, the rows locked are those
|
|
returned to the outer query by the sub-query. This might involve
|
|
fewer rows than inspection of the sub-query alone would suggest,
|
|
since conditions from the outer query might be used to optimize
|
|
execution of the sub-query. For example,
|
|
<programlisting>
|
|
SELECT * FROM (SELECT * FROM mytable FOR UPDATE) ss WHERE col1 = 5;
|
|
</programlisting>
|
|
will lock only rows having <literal>col1 = 5</>, even though that
|
|
condition is not textually within the sub-query.
|
|
</para>
|
|
|
|
<para>
|
|
Previous releases failed to preserve a lock which is upgraded by a later
|
|
savepoint. For example, this code:
|
|
<programlisting>
|
|
BEGIN;
|
|
SELECT * FROM mytable WHERE key = 1 FOR UPDATE;
|
|
SAVEPOINT s;
|
|
UPDATE mytable SET ... WHERE key = 1;
|
|
ROLLBACK TO s;
|
|
</programlisting>
|
|
would fail to preserve the <literal>FOR UPDATE</> lock after the
|
|
<command>ROLLBACK TO</>. This has been fixed in release 9.3.
|
|
</para>
|
|
|
|
<caution>
|
|
<para>
|
|
It is possible for a <command>SELECT</> command running at the <literal>READ
|
|
COMMITTED</literal> transaction isolation level and using <literal>ORDER
|
|
BY</literal> and a locking clause to return rows out of
|
|
order. This is because <literal>ORDER BY</> is applied first.
|
|
The command sorts the result, but might then block trying to obtain a lock
|
|
on one or more of the rows. Once the <literal>SELECT</> unblocks, some
|
|
of the ordering column values might have been modified, leading to those
|
|
rows appearing to be out of order (though they are in order in terms
|
|
of the original column values). This can be worked around at need by
|
|
placing the <literal>FOR UPDATE/SHARE</literal> clause in a sub-query,
|
|
for example
|
|
<programlisting>
|
|
SELECT * FROM (SELECT * FROM mytable FOR UPDATE) ss ORDER BY column1;
|
|
</programlisting>
|
|
Note that this will result in locking all rows of <structname>mytable</>,
|
|
whereas <literal>FOR UPDATE</> at the top level would lock only the
|
|
actually returned rows. This can make for a significant performance
|
|
difference, particularly if the <literal>ORDER BY</> is combined with
|
|
<literal>LIMIT</> or other restrictions. So this technique is recommended
|
|
only if concurrent updates of the ordering columns are expected and a
|
|
strictly sorted result is required.
|
|
</para>
|
|
|
|
<para>
|
|
At the <literal>REPEATABLE READ</literal> or <literal>SERIALIZABLE</literal>
|
|
transaction isolation level this would cause a serialization failure (with
|
|
a <literal>SQLSTATE</literal> of <literal>'40001'</literal>), so there is
|
|
no possibility of receiving rows out of order under these isolation levels.
|
|
</para>
|
|
</caution>
|
|
</refsect2>
|
|
|
|
<refsect2 id="SQL-TABLE">
|
|
<title><literal>TABLE</literal> Command</title>
|
|
|
|
<para>
|
|
The command
|
|
<programlisting>
|
|
TABLE <replaceable class="parameter">name</replaceable>
|
|
</programlisting>
|
|
is equivalent to
|
|
<programlisting>
|
|
SELECT * FROM <replaceable class="parameter">name</replaceable>
|
|
</programlisting>
|
|
It can be used as a top-level command or as a space-saving syntax
|
|
variant in parts of complex queries. Only the <literal>WITH</>,
|
|
<literal>UNION</>, <literal>INTERSECT</>, <literal>EXCEPT</>,
|
|
<literal>ORDER BY</>, <literal>LIMIT</>, <literal>OFFSET</>,
|
|
<literal>FETCH</> and <literal>FOR</> locking clauses can be used
|
|
with <command>TABLE</>; the <literal>WHERE</> clause and any form of
|
|
aggregation cannot
|
|
be used.
|
|
</para>
|
|
</refsect2>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Examples</title>
|
|
|
|
<para>
|
|
To join the table <literal>films</literal> with the table
|
|
<literal>distributors</literal>:
|
|
|
|
<programlisting>
|
|
SELECT f.title, f.did, d.name, f.date_prod, f.kind
|
|
FROM distributors d, films f
|
|
WHERE f.did = d.did
|
|
|
|
title | did | name | date_prod | kind
|
|
-------------------+-----+--------------+------------+----------
|
|
The Third Man | 101 | British Lion | 1949-12-23 | Drama
|
|
The African Queen | 101 | British Lion | 1951-08-11 | Romantic
|
|
...
|
|
</programlisting>
|
|
</para>
|
|
|
|
<para>
|
|
To sum the column <literal>len</literal> of all films and group
|
|
the results by <literal>kind</literal>:
|
|
|
|
<programlisting>
|
|
SELECT kind, sum(len) AS total FROM films GROUP BY kind;
|
|
|
|
kind | total
|
|
----------+-------
|
|
Action | 07:34
|
|
Comedy | 02:58
|
|
Drama | 14:28
|
|
Musical | 06:42
|
|
Romantic | 04:38
|
|
</programlisting>
|
|
</para>
|
|
|
|
<para>
|
|
To sum the column <literal>len</literal> of all films, group
|
|
the results by <literal>kind</literal> and show those group totals
|
|
that are less than 5 hours:
|
|
|
|
<programlisting>
|
|
SELECT kind, sum(len) AS total
|
|
FROM films
|
|
GROUP BY kind
|
|
HAVING sum(len) < interval '5 hours';
|
|
|
|
kind | total
|
|
----------+-------
|
|
Comedy | 02:58
|
|
Romantic | 04:38
|
|
</programlisting>
|
|
</para>
|
|
|
|
<para>
|
|
The following two examples are identical ways of sorting the individual
|
|
results according to the contents of the second column
|
|
(<literal>name</literal>):
|
|
|
|
<programlisting>
|
|
SELECT * FROM distributors ORDER BY name;
|
|
SELECT * FROM distributors ORDER BY 2;
|
|
|
|
did | name
|
|
-----+------------------
|
|
109 | 20th Century Fox
|
|
110 | Bavaria Atelier
|
|
101 | British Lion
|
|
107 | Columbia
|
|
102 | Jean Luc Godard
|
|
113 | Luso films
|
|
104 | Mosfilm
|
|
103 | Paramount
|
|
106 | Toho
|
|
105 | United Artists
|
|
111 | Walt Disney
|
|
112 | Warner Bros.
|
|
108 | Westward
|
|
</programlisting>
|
|
</para>
|
|
|
|
<para>
|
|
The next example shows how to obtain the union of the tables
|
|
<literal>distributors</literal> and
|
|
<literal>actors</literal>, restricting the results to those that begin
|
|
with the letter W in each table. Only distinct rows are wanted, so the
|
|
key word <literal>ALL</literal> is omitted.
|
|
|
|
<programlisting>
|
|
distributors: actors:
|
|
did | name id | name
|
|
-----+-------------- ----+----------------
|
|
108 | Westward 1 | Woody Allen
|
|
111 | Walt Disney 2 | Warren Beatty
|
|
112 | Warner Bros. 3 | Walter Matthau
|
|
... ...
|
|
|
|
SELECT distributors.name
|
|
FROM distributors
|
|
WHERE distributors.name LIKE 'W%'
|
|
UNION
|
|
SELECT actors.name
|
|
FROM actors
|
|
WHERE actors.name LIKE 'W%';
|
|
|
|
name
|
|
----------------
|
|
Walt Disney
|
|
Walter Matthau
|
|
Warner Bros.
|
|
Warren Beatty
|
|
Westward
|
|
Woody Allen
|
|
</programlisting>
|
|
</para>
|
|
|
|
<para>
|
|
This example shows how to use a function in the <literal>FROM</>
|
|
clause, both with and without a column definition list:
|
|
|
|
<programlisting>
|
|
CREATE FUNCTION distributors(int) RETURNS SETOF distributors AS $$
|
|
SELECT * FROM distributors WHERE did = $1;
|
|
$$ LANGUAGE SQL;
|
|
|
|
SELECT * FROM distributors(111);
|
|
did | name
|
|
-----+-------------
|
|
111 | Walt Disney
|
|
|
|
CREATE FUNCTION distributors_2(int) RETURNS SETOF record AS $$
|
|
SELECT * FROM distributors WHERE did = $1;
|
|
$$ LANGUAGE SQL;
|
|
|
|
SELECT * FROM distributors_2(111) AS (f1 int, f2 text);
|
|
f1 | f2
|
|
-----+-------------
|
|
111 | Walt Disney
|
|
</programlisting>
|
|
</para>
|
|
|
|
<para>
|
|
Here is an example of a function with an ordinality column added:
|
|
|
|
<programlisting>
|
|
SELECT * FROM unnest(ARRAY['a','b','c','d','e','f']) WITH ORDINALITY;
|
|
unnest | ordinality
|
|
--------+----------
|
|
a | 1
|
|
b | 2
|
|
c | 3
|
|
d | 4
|
|
e | 5
|
|
f | 6
|
|
(6 rows)
|
|
</programlisting>
|
|
</para>
|
|
|
|
<para>
|
|
This example shows how to use a simple <literal>WITH</> clause:
|
|
|
|
<programlisting>
|
|
WITH t AS (
|
|
SELECT random() as x FROM generate_series(1, 3)
|
|
)
|
|
SELECT * FROM t
|
|
UNION ALL
|
|
SELECT * FROM t
|
|
|
|
x
|
|
--------------------
|
|
0.534150459803641
|
|
0.520092216785997
|
|
0.0735620250925422
|
|
0.534150459803641
|
|
0.520092216785997
|
|
0.0735620250925422
|
|
</programlisting>
|
|
|
|
Notice that the <literal>WITH</> query was evaluated only once,
|
|
so that we got two sets of the same three random values.
|
|
</para>
|
|
|
|
<para>
|
|
This example uses <literal>WITH RECURSIVE</literal> to find all
|
|
subordinates (direct or indirect) of the employee Mary, and their
|
|
level of indirectness, from a table that shows only direct
|
|
subordinates:
|
|
|
|
<programlisting>
|
|
WITH RECURSIVE employee_recursive(distance, employee_name, manager_name) AS (
|
|
SELECT 1, employee_name, manager_name
|
|
FROM employee
|
|
WHERE manager_name = 'Mary'
|
|
UNION ALL
|
|
SELECT er.distance + 1, e.employee_name, e.manager_name
|
|
FROM employee_recursive er, employee e
|
|
WHERE er.employee_name = e.manager_name
|
|
)
|
|
SELECT distance, employee_name FROM employee_recursive;
|
|
</programlisting>
|
|
|
|
Notice the typical form of recursive queries:
|
|
an initial condition, followed by <literal>UNION</literal>,
|
|
followed by the recursive part of the query. Be sure that the
|
|
recursive part of the query will eventually return no tuples, or
|
|
else the query will loop indefinitely. (See <xref linkend="queries-with">
|
|
for more examples.)
|
|
</para>
|
|
|
|
<para>
|
|
This example uses <literal>LATERAL</> to apply a set-returning function
|
|
<function>get_product_names()</> for each row of the
|
|
<structname>manufacturers</> table:
|
|
|
|
<programlisting>
|
|
SELECT m.name AS mname, pname
|
|
FROM manufacturers m, LATERAL get_product_names(m.id) pname;
|
|
</programlisting>
|
|
|
|
Manufacturers not currently having any products would not appear in the
|
|
result, since it is an inner join. If we wished to include the names of
|
|
such manufacturers in the result, we could do:
|
|
|
|
<programlisting>
|
|
SELECT m.name AS mname, pname
|
|
FROM manufacturers m LEFT JOIN LATERAL get_product_names(m.id) pname ON true;
|
|
</programlisting></para>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Compatibility</title>
|
|
|
|
<para>
|
|
Of course, the <command>SELECT</command> statement is compatible
|
|
with the SQL standard. But there are some extensions and some
|
|
missing features.
|
|
</para>
|
|
|
|
<refsect2>
|
|
<title>Omitted <literal>FROM</literal> Clauses</title>
|
|
|
|
<para>
|
|
<productname>PostgreSQL</productname> allows one to omit the
|
|
<literal>FROM</literal> clause. It has a straightforward use to
|
|
compute the results of simple expressions:
|
|
<programlisting>
|
|
SELECT 2+2;
|
|
|
|
?column?
|
|
----------
|
|
4
|
|
</programlisting>
|
|
Some other <acronym>SQL</acronym> databases cannot do this except
|
|
by introducing a dummy one-row table from which to do the
|
|
<command>SELECT</command>.
|
|
</para>
|
|
|
|
<para>
|
|
Note that if a <literal>FROM</literal> clause is not specified,
|
|
the query cannot reference any database tables. For example, the
|
|
following query is invalid:
|
|
<programlisting>
|
|
SELECT distributors.* WHERE distributors.name = 'Westward';
|
|
</programlisting>
|
|
<productname>PostgreSQL</productname> releases prior to
|
|
8.1 would accept queries of this form, and add an implicit entry
|
|
to the query's <literal>FROM</literal> clause for each table
|
|
referenced by the query. This is no longer allowed.
|
|
</para>
|
|
</refsect2>
|
|
|
|
<refsect2>
|
|
<title>Empty <literal>SELECT</literal> Lists</title>
|
|
|
|
<para>
|
|
The list of output expressions after <literal>SELECT</literal> can be
|
|
empty, producing a zero-column result table.
|
|
This is not valid syntax according to the SQL standard.
|
|
<productname>PostgreSQL</productname> allows it to be consistent with
|
|
allowing zero-column tables.
|
|
However, an empty list is not allowed when <literal>DISTINCT</> is used.
|
|
</para>
|
|
</refsect2>
|
|
|
|
<refsect2>
|
|
<title>Omitting the <literal>AS</literal> Key Word</title>
|
|
|
|
<para>
|
|
In the SQL standard, the optional key word <literal>AS</> can be
|
|
omitted before an output column name whenever the new column name
|
|
is a valid column name (that is, not the same as any reserved
|
|
keyword). <productname>PostgreSQL</productname> is slightly more
|
|
restrictive: <literal>AS</> is required if the new column name
|
|
matches any keyword at all, reserved or not. Recommended practice is
|
|
to use <literal>AS</> or double-quote output column names, to prevent
|
|
any possible conflict against future keyword additions.
|
|
</para>
|
|
|
|
<para>
|
|
In <literal>FROM</literal> items, both the standard and
|
|
<productname>PostgreSQL</productname> allow <literal>AS</> to
|
|
be omitted before an alias that is an unreserved keyword. But
|
|
this is impractical for output column names, because of syntactic
|
|
ambiguities.
|
|
</para>
|
|
</refsect2>
|
|
|
|
<refsect2>
|
|
<title><literal>ONLY</literal> and Inheritance</title>
|
|
|
|
<para>
|
|
The SQL standard requires parentheses around the table name when
|
|
writing <literal>ONLY</literal>, for example <literal>SELECT * FROM ONLY
|
|
(tab1), ONLY (tab2) WHERE ...</literal>. <productname>PostgreSQL</>
|
|
considers these parentheses to be optional.
|
|
</para>
|
|
|
|
<para>
|
|
<productname>PostgreSQL</> allows a trailing <literal>*</> to be written to
|
|
explicitly specify the non-<literal>ONLY</literal> behavior of including
|
|
child tables. The standard does not allow this.
|
|
</para>
|
|
|
|
<para>
|
|
(These points apply equally to all SQL commands supporting the
|
|
<literal>ONLY</literal> option.)
|
|
</para>
|
|
</refsect2>
|
|
|
|
<refsect2>
|
|
<title><literal>TABLESAMPLE</literal> Clause Restrictions</title>
|
|
|
|
<para>
|
|
The <literal>TABLESAMPLE</> clause is currently accepted only on
|
|
regular tables and materialized views. According to the SQL standard
|
|
it should be possible to apply it to any <literal>FROM</> item.
|
|
</para>
|
|
</refsect2>
|
|
|
|
<refsect2>
|
|
<title>Function Calls in <literal>FROM</literal></title>
|
|
|
|
<para>
|
|
<productname>PostgreSQL</productname> allows a function call to be
|
|
written directly as a member of the <literal>FROM</> list. In the SQL
|
|
standard it would be necessary to wrap such a function call in a
|
|
sub-<command>SELECT</command>; that is, the syntax
|
|
<literal>FROM <replaceable>func</>(...) <replaceable>alias</></literal>
|
|
is approximately equivalent to
|
|
<literal>FROM LATERAL (SELECT <replaceable>func</>(...)) <replaceable>alias</></literal>.
|
|
Note that <literal>LATERAL</> is considered to be implicit; this is
|
|
because the standard requires <literal>LATERAL</> semantics for an
|
|
<literal>UNNEST()</> item in <literal>FROM</>.
|
|
<productname>PostgreSQL</productname> treats <literal>UNNEST()</> the
|
|
same as other set-returning functions.
|
|
</para>
|
|
</refsect2>
|
|
|
|
<refsect2>
|
|
<title>Namespace Available to <literal>GROUP BY</literal> and <literal>ORDER BY</literal></title>
|
|
|
|
<para>
|
|
In the SQL-92 standard, an <literal>ORDER BY</literal> clause can
|
|
only use output column names or numbers, while a <literal>GROUP
|
|
BY</literal> clause can only use expressions based on input column
|
|
names. <productname>PostgreSQL</productname> extends each of
|
|
these clauses to allow the other choice as well (but it uses the
|
|
standard's interpretation if there is ambiguity).
|
|
<productname>PostgreSQL</productname> also allows both clauses to
|
|
specify arbitrary expressions. Note that names appearing in an
|
|
expression will always be taken as input-column names, not as
|
|
output-column names.
|
|
</para>
|
|
|
|
<para>
|
|
SQL:1999 and later use a slightly different definition which is not
|
|
entirely upward compatible with SQL-92.
|
|
In most cases, however, <productname>PostgreSQL</productname>
|
|
will interpret an <literal>ORDER BY</literal> or <literal>GROUP
|
|
BY</literal> expression the same way SQL:1999 does.
|
|
</para>
|
|
</refsect2>
|
|
|
|
<refsect2>
|
|
<title>Functional Dependencies</title>
|
|
|
|
<para>
|
|
<productname>PostgreSQL</productname> recognizes functional dependency
|
|
(allowing columns to be omitted from <literal>GROUP BY</>) only when
|
|
a table's primary key is included in the <literal>GROUP BY</> list.
|
|
The SQL standard specifies additional conditions that should be
|
|
recognized.
|
|
</para>
|
|
</refsect2>
|
|
|
|
<refsect2>
|
|
<title><literal>WINDOW</literal> Clause Restrictions</title>
|
|
|
|
<para>
|
|
The SQL standard provides additional options for the window
|
|
<replaceable class="parameter">frame_clause</>.
|
|
<productname>PostgreSQL</productname> currently supports only the
|
|
options listed above.
|
|
</para>
|
|
</refsect2>
|
|
|
|
<refsect2>
|
|
<title><literal>LIMIT</literal> and <literal>OFFSET</literal></title>
|
|
|
|
<para>
|
|
The clauses <literal>LIMIT</literal> and <literal>OFFSET</literal>
|
|
are <productname>PostgreSQL</productname>-specific syntax, also
|
|
used by <productname>MySQL</productname>. The SQL:2008 standard
|
|
has introduced the clauses <literal>OFFSET ... FETCH {FIRST|NEXT}
|
|
...</literal> for the same functionality, as shown above
|
|
in <xref linkend="sql-limit" endterm="sql-limit-title">. This
|
|
syntax is also used by <productname>IBM DB2</productname>.
|
|
(Applications written for <productname>Oracle</productname>
|
|
frequently use a workaround involving the automatically
|
|
generated <literal>rownum</literal> column, which is not available in
|
|
PostgreSQL, to implement the effects of these clauses.)
|
|
</para>
|
|
</refsect2>
|
|
|
|
<refsect2>
|
|
<title><literal>FOR NO KEY UPDATE</>, <literal>FOR UPDATE</>, <literal>FOR SHARE</>, <literal>FOR KEY SHARE</></title>
|
|
|
|
<para>
|
|
Although <literal>FOR UPDATE</> appears in the SQL standard, the
|
|
standard allows it only as an option of <command>DECLARE CURSOR</>.
|
|
<productname>PostgreSQL</productname> allows it in any <command>SELECT</>
|
|
query as well as in sub-<command>SELECT</>s, but this is an extension.
|
|
The <literal>FOR NO KEY UPDATE</>, <literal>FOR SHARE</> and
|
|
<literal>FOR KEY SHARE</> variants, as well as the <literal>NOWAIT</>
|
|
and <literal>SKIP LOCKED</literal> options, do not appear in the
|
|
standard.
|
|
</para>
|
|
</refsect2>
|
|
|
|
<refsect2>
|
|
<title>Data-Modifying Statements in <literal>WITH</></title>
|
|
|
|
<para>
|
|
<productname>PostgreSQL</productname> allows <command>INSERT</>,
|
|
<command>UPDATE</>, and <command>DELETE</> to be used as <literal>WITH</>
|
|
queries. This is not found in the SQL standard.
|
|
</para>
|
|
</refsect2>
|
|
|
|
<refsect2>
|
|
<title>Nonstandard Clauses</title>
|
|
|
|
<para>
|
|
<literal>DISTINCT ON ( ... )</literal> is an extension of the
|
|
SQL standard.
|
|
</para>
|
|
|
|
<para>
|
|
<literal>ROWS FROM( ... )</> is an extension of the SQL standard.
|
|
</para>
|
|
</refsect2>
|
|
|
|
</refsect1>
|
|
</refentry>
|