+ linkend="sql-limit" endterm="sql-limit-title"> below.)
+
+
+
The FOR UPDATE clause causes the
- A JOIN clause, combines two
- FROM> items. (Use parentheses if necessary to
- determine the order of nesting.)
+ A JOIN clause combines two
+ FROM> items. Use parentheses if necessary to
+ determine the order of nesting. In the absence of parentheses,
+ JOINs nest left-to-right. In any case
+ JOIN binds more tightly than the commas
+ separating FROM> items.
CROSS JOIN> and INNER JOIN
- produce a simple Cartesian product, the same as you get from
- listing the two items at the top level of FROM>.
+ produce a simple Cartesian product, the same result as you get from
+ listing the two items at the top level of FROM>,
+ but restricted by the join condition (if any).
CROSS JOIN> is equivalent to INNER JOIN ON
- (true)>, that is, no rows are removed by qualification.
+ (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 FROM> and
WHERE>.
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 JOIN>
- clauses own condition is considered while deciding which rows
+ clause's own condition is considered while deciding which rows
have matches. Outer conditions are applied afterwards.
expressions.
class="parameter">expression can be an input column
name, or the name or ordinal number of an output column
- (SELECT list), or it can be an arbitrary
+ (SELECT list item), or an arbitrary
expression formed from input-column values. In case of ambiguity,
a GROUP BY name will be interpreted as an
input-column name rather than an output column name.
Currently, FOR UPDATE> may not be specified either for
- a UNION> result or for the inputs of UNION>.
+ a UNION> result or for any input of a UNION>.
expression can be the
name or ordinal number of an output column
- (SELECT list), or it can be an arbitrary
+ (SELECT list item), or it can be an arbitrary
expression formed from input-column values.
equal according to the leftmost expression, the are compared
according to the next expression and so on. If they are equal
according to all specified expressions, they are returned in
- random order.
+ an implementation-dependent order.
Optionally one may add the key word ASC> (ascending) or
- DESC> (descending) after each expression in the
+ DESC> (descending) after any expression in the
ORDER BY> clause. If not specified, ASC> is
assumed by default. Alternatively, a specific ordering operator
name may be specified in the USING> clause.
The LIMIT clause consists of two independent
- clauses:
+ sub-clauses:
LIMIT { count | ALL }
OFFSET start
count specifies the
- maximum number of rows to return,
and
+ maximum number of rows to return,
while
class="parameter">start specifies the number of rows
- to skip before starting to return rows.
+ to skip before starting to return rows. When both are specified,
+ start rows are skipped
+ before starting to count the
+ class="parameter">count rows to be returned.
of time values for each location, we'd have gotten a report from
an unpredictable time for each location.
+
+ The DISTINCT ON> expression(s) must match the leftmost
+ ORDER BY> expression(s). The ORDER BY> clause
+ will normally contain additional expression(s) that determine the
+ desired precedence of rows within each DISTINCT ON> group.
+
- This example shows how to obtain the union of the tables
+ The next example shows how to obtain the union of the tables
distributors and
actors, restricting the results to those that begin
- with letter W in each table. Only distinct rows are wanted, so the
+ with the letter W in each table. Only distinct rows are wanted, so the
key word ALL is omitted.
This example shows how to use a function in the FROM>
- clause, both with and without a column definition list.
+ clause, both with and without a column definition list:
CREATE FUNCTION distributors(int) RETURNS SETOF distributors AS '
- SQL99 uses a slightly different definition which is not upward compatible
+ SQL99 uses a slightly different definition which is not entirely upward
+ compatible
with SQL92. In most cases, however,
PostgreSQL
will interpret an ORDER BY or GROUP
BY expression the same way SQL99 does.