[ { UNION | INTERSECT | EXCEPT } [ ALL ] select ]
[ ORDER BY expression [ ASC | DESC | USING operator ] [ NULLS { FIRST | LAST } ] [, ...] ]
[ LIMIT { count | ALL } ]
- [ OFFSET start ]
+ [ OFFSET start [ ROW | ROWS ] ]
+ [ FETCH { FIRST | NEXT } [ count ] { ROW | ROWS } ONLY ]
[ FOR { UPDATE | SHARE } [ OF table_name [, ...] ] [ NOWAIT ] [...] ]
where from_item can be one of:
- If the LIMIT or OFFSET
+ If the LIMIT (or FETCH FIRST) or OFFSET
clause is specified, the SELECT statement
only returns a subset of the result rows. (See
linkend="sql-limit" endterm="sql-limit-title"> below.)
class="parameter">count rows to be returned.
+ SQL:2008 introduced a different syntax to achieve the same thing,
+ which PostgreSQL also supports. It is:
+
+OFFSET start { ROW | ROWS }
+FETCH { FIRST | NEXT } [ count ] { ROW | ROWS } ONLY
+
+ Both clauses are optional, but if present
+ the OFFSET clause must come before
+ the FETCH clause. ROW
+ and ROWS as well as FIRST
+ and NEXT are noise words that don't influence
+ the effects of these clauses. When using expressions other than
+ constants for the offset or fetch count, parentheses will be
+ necessary in most cases. If the fetch count is omitted, it
+ defaults to 1.
+
+
When using LIMIT, it is a good idea to use an
ORDER BY clause that constrains the result rows into a
+
+
<literal>LIMIT</literal> and <literal>OFFSET</literal>
+
+ The clauses LIMIT and OFFSET
+ are
PostgreSQL-specific syntax, also
+ used by
MySQL. The SQL:2008 standard
+ has introduced the clauses OFFSET ... FETCH {FIRST|NEXT}
+ ... for the same functionality, as shown above
+ in , and this
+ syntax is also used by
IBM DB2.
+ (Applications written for
Oracle+ frequently use a workaround involving the automatically
+ generated rownum column, not available in
+ PostgreSQL, to implement the effects of these clauses.)
+
+
+
Nonstandard Clauses
- The clauses DISTINCT ON,
- LIMIT, and OFFSET are not
- defined in the SQL standard.
+ The clause DISTINCT ON is not defined in the
+ SQL standard.
[ { UNION | INTERSECT | EXCEPT } [ ALL ] select ]
[ ORDER BY expression [ ASC | DESC | USING operator ] [ NULLS { FIRST | LAST } ] [, ...] ]
[ LIMIT { count | ALL } ]
- [ OFFSET start ]
+ [ OFFSET start [ ROW | ROWS ] ]
+ [ FETCH { FIRST | NEXT } [ count ] { ROW | ROWS } ONLY ]
[ FOR { UPDATE | SHARE } [ OF table_name [, ...] ] [ NOWAIT ] [...] ]
VALUES ( expression [, ...] ) [, ...]
[ ORDER BY sort_expression [ ASC | DESC | USING operator ] [, ...] ]
[ LIMIT { count | ALL } ]
- [ OFFSET start ]
+ [ OFFSET start [ ROW | ROWS ] ]
+ [ FETCH { FIRST | NEXT } [ count ] { ROW | ROWS } ONLY ]
Within larger commands, VALUES is syntactically allowed
anywhere that SELECT is. Because it is treated like a
- SELECT by the grammar, it is possible to use the ORDER
- BY, LIMIT, and OFFSET clauses with a
+ SELECT by the grammar, it is possible to use
+ the ORDER BY, LIMIT (or
+ equivalently FETCH FIRST),
+ and OFFSET clauses with a
VALUES command.
Compatibility
- VALUES conforms to the SQL standard, except that
+ VALUES conforms to the SQL standard.
LIMIT and OFFSET are
+
PostgreSQL extensions; see also
+ under .
F852 Top-level in views YES
F855 Nested in YES
F856 Nested in YES
-F857 Top-level in NO same as LIMIT
-F858 in subqueries NO same as LIMIT
-F859 Top-level in views NO same as LIMIT
-F860 in NO same as LIMIT
-F861 Top-level in NO same as OFFSET
-F862 in subqueries NO same as OFFSET
-F863 Nested in NO same as OFFSET
-F864 Top-level in views NO same as OFFSET
-F865 in NO same as OFFSET
+F857 Top-level in YES
+F858 in subqueries YES
+F859 Top-level in views YES
+F860 in YES
+F861 Top-level in YES
+F862 in subqueries YES
+F863 Nested in YES
+F864 Top-level in views YES
+F865 in YES
S011 Distinct data types NO
S011 Distinct data types 01 USER_DEFINED_TYPES view NO
S023 Basic structured types NO
*
*
* IDENTIFICATION
- * $PostgreSQL: pgsql/src/backend/parser/gram.y,v 2.627 2008/10/21 08:38:15 petere Exp $
+ * $PostgreSQL: pgsql/src/backend/parser/gram.y,v 2.628 2008/10/22 11:00:34 petere Exp $
*
* HISTORY
* AUTHOR DATE MAJOR EVENT
%type reindex_type drop_type comment_type
%type fetch_direction select_limit_value select_offset_value
+ select_offset_value2 opt_select_fetch_first_value
+%type row_or_rows first_or_next
%type OptSeqOptList SeqOptList
%type SeqOptElem
errhint("Use separate LIMIT and OFFSET clauses."),
scanner_errposition(@1)));
}
+ /* SQL:2008 syntax variants */
+ | OFFSET select_offset_value2 row_or_rows
+ { $$ = list_make2($2, NULL); }
+ | FETCH first_or_next opt_select_fetch_first_value row_or_rows ONLY
+ { $$ = list_make2(NULL, $3); }
+ | OFFSET select_offset_value2 row_or_rows FETCH first_or_next opt_select_fetch_first_value row_or_rows ONLY
+ { $$ = list_make2($2, $6); }
;
opt_select_limit:
}
;
+/*
+ * Allowing full expressions without parentheses causes various parsing
+ * problems with the trailing ROW/ROWS key words. SQL only calls for
+ * constants, so we allow the rest only with parentheses.
+ */
+opt_select_fetch_first_value:
+ SignedIconst { $$ = makeIntConst($1, @1); }
+ | '(' a_expr ')' { $$ = $2; }
+ | /*EMPTY*/ { $$ = makeIntConst(1, -1); }
+ ;
+
select_offset_value:
a_expr { $$ = $1; }
;
+/*
+ * Again, the trailing ROW/ROWS in this case prevent the full expression
+ * syntax. c_expr is the best we can do.
+ */
+select_offset_value2:
+ c_expr { $$ = $1; }
+ ;
+
+/* noise words */
+row_or_rows:
+ ROW { $$ = 0; }
+ | ROWS { $$ = 0; }
+
+/* noise words */
+first_or_next:
+ FIRST_P { $$ = 0; }
+ | NEXT { $$ = 0; }
+
+
group_clause:
GROUP_P BY expr_list { $$ = $3; }
| /*EMPTY*/ { $$ = NIL; }
RoleId: ColId { $$ = $1; };
SignedIconst: ICONST { $$ = $1; }
+ | '+' ICONST { $$ = + $2; }
| '-' ICONST { $$ = - $2; }
;
| EXPLAIN
| EXTERNAL
| FAMILY
- | FETCH
| FIRST_P
| FORCE
| FORWARD
| END_P
| EXCEPT
| FALSE_P
+ | FETCH
| FOR
| FOREIGN
| FROM
*
*
* IDENTIFICATION
- * $PostgreSQL: pgsql/src/backend/parser/keywords.c,v 1.203 2008/10/21 08:38:15 petere Exp $
+ * $PostgreSQL: pgsql/src/backend/parser/keywords.c,v 1.204 2008/10/22 11:00:34 petere Exp $
*
*-------------------------------------------------------------------------
*/
{"extract", EXTRACT, COL_NAME_KEYWORD},
{"false", FALSE_P, RESERVED_KEYWORD},
{"family", FAMILY, UNRESERVED_KEYWORD},
- {"fetch", FETCH, UNRESERVED_KEYWORD},
+ {"fetch", FETCH, RESERVED_KEYWORD},
{"first", FIRST_P, UNRESERVED_KEYWORD},
{"float", FLOAT_P, COL_NAME_KEYWORD},
{"for", FOR, RESERVED_KEYWORD},
projects / postgresql.git / commitdiff