Implement TODO item:
authorBruce Momjian
Sun, 23 Sep 2001 03:39:01 +0000 (03:39 +0000)
committerBruce Momjian
Sun, 23 Sep 2001 03:39:01 +0000 (03:39 +0000)
* Change LIMIT val,val to offset,limit to match MySQL

Documentation updates too.

doc/TODO
doc/src/sgml/ref/select.sgml
doc/src/sgml/sql.sgml
src/backend/parser/gram.y

index 963c17618eb870528b9e0e3c416705cb918c6bde..e7053aae28189b2f16c26166aca69ad1c3cd0bfd 100644 (file)
--- a/doc/TODO
+++ b/doc/TODO
@@ -74,10 +74,10 @@ TYPES
    o Allow nulls in arrays
    o Allow arrays to be ORDER'ed
    o fix array handling in ECPG
-BINARY DATA
+lfBINARY DATA
    o -Add non-large-object binary field (already exists -- bytea)
    o -Make binary interface for TOAST columns (base64)
-   o Improve vacuum of large objects (/contrib/vacuumlo)
+   o Improve vacuum of large objects, like /contrib/vacuumlo
    o Add security checking for large objects
    o Make file in/out interface for TOAST columns, similar to large object
      interface (force out-of-line storage and no compression)
@@ -105,7 +105,7 @@ INDEXES
 * Allow CREATE INDEX zman_index ON test (date_trunc( 'day', zman ) datetime_ops)
   fails index can't store constant parameters
 * Add FILLFACTOR to index creation
-* Order duplicate index entries by tid
+* Order duplicate index entries by tid for faster heap lookups
 * -Re-enable partial indexes
 * -Prevent pg_attribute from having duplicate oids for indexes (Tom)
 * Allow inherited tables to inherit index, UNIQUE constraint, and primary
@@ -124,7 +124,7 @@ INDEXES
   non-consecutive keys or OR clauses, so fewer heap accesses
 * Allow SELECT * FROM tab WHERE int2col = 4 to use int2col index, int8,
   float4, numeric/decimal too [optimizer]
-* Use indexes with CIDR '<<' (contains) operator
+* -Use indexes with CIDR '<<' (contains) operator
 * Allow LIKE indexing optimization for non-ASCII locales
 * Be smarter about insertion of already-ordered data into btree index
 * -Gather more accurate dispersion statistics using indexes (Tom)
index 2e1e552f264838605bc2998405375f27855367aa..e8dc02498ca989d571d1aea7dc12055dc4861431 100644 (file)
@@ -1,5 +1,5 @@
 
 
@@ -29,7 +29,8 @@ SELECT [ ALL | DISTINCT [ ON ( expression
     [ { UNION | INTERSECT | EXCEPT [ ALL ] } select ]
     [ ORDER BY expression [ ASC | DESC | USING operator ] [, ...] ]
     [ FOR UPDATE [ OF tablename [, ...] ] ]
-    [ LIMIT { count | ALL } [ { OFFSET | , } start ]]
+    [ LIMIT [ start , ] { count | ALL } ]
+    [ OFFSET start ]
 
 where from_item can be:
 
@@ -613,7 +614,8 @@ SELECT name FROM distributors ORDER BY code;
     
 table_query UNION [ ALL ] table_query
     [ ORDER BY expression [ ASC | DESC | USING operator ] [, ...] ]
-    [ LIMIT { count | ALL } [ { OFFSET | , } start ]]
+    [ LIMIT [ start , ] { count | ALL } ]
+    [ OFFSET start ]
     
 
     where
@@ -662,7 +664,8 @@ SELECT name FROM distributors ORDER BY code;
     
 table_query INTERSECT [ ALL ] table_query
     [ ORDER BY expression [ ASC | DESC | USING operator ] [, ...] ]
-    [ LIMIT { count | ALL } [ { OFFSET | , } start ]]
+    [ LIMIT [ start , ] { count | ALL } ]
+    [ OFFSET start ]
     
     
     where
@@ -702,7 +705,8 @@ SELECT name FROM distributors ORDER BY code;
     
 table_query EXCEPT [ ALL ] table_query
     [ ORDER BY expression [ ASC | DESC | USING operator ] [, ...] ]
-    [ LIMIT { count | ALL } [ { OFFSET | , } start ]]
+    [ LIMIT [ start , ] { count | ALL } ]
+    [ OFFSET start ]
     
     
     where
@@ -738,7 +742,7 @@ SELECT name FROM distributors ORDER BY code;
    
    
     
-    LIMIT count | ALL } [ { OFFSET | , } start ]
+    LIMIT start , ] { count | ALL }
     OFFSET start
     
     
@@ -761,14 +765,14 @@ SELECT name FROM distributors ORDER BY code;
     constrains the result rows into a unique order.  Otherwise you will get
     an unpredictable subset of the query's rows---you may be asking for
     the tenth through twentieth rows, but tenth through twentieth in what
-    ordering?  You don't know what ordering, unless you specified ORDER BY.
+    ordering?  You don't know what ordering unless you specify ORDER BY.
    
 
    
     As of Postgres 7.0, the
     query optimizer takes 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 give for LIMIT and OFFSET.  Thus, using
+    orders) depending on what you use for LIMIT and OFFSET.  Thus, using
     different LIMIT/OFFSET values to select different subsets of a query
     result will give inconsistent results unless
     you enforce a predictable result ordering with ORDER BY.  This is not
index d0eef867abf9dea9200c2fa2f2f2a343660f87d2..223aee1bc692ca8325115a9fb1fda2020c9b7299 100644 (file)
@@ -1,5 +1,5 @@
 
 
  
@@ -864,7 +864,8 @@ SELECT [ ALL | DISTINCT [ ON ( expression
     [ { UNION | INTERSECT | EXCEPT [ ALL ] } select ]
     [ ORDER BY expression [ ASC | DESC | USING operator ] [, ...] ]
     [ FOR UPDATE [ OF class_name [, ...] ] ]
-    [ LIMIT { count | ALL } [ { OFFSET | , } start ]]
+    [ LIMIT [ start , ] { count | ALL } ]
+    [ OFFSET start ]
      
     
 
index 24407902bd36d8fd899d6091e46d055738468db1..64d71d28bd7d73cee76569fe48b235710ea0bfa3 100644 (file)
@@ -11,7 +11,7 @@
  *
  *
  * IDENTIFICATION
- *   $Header: /cvsroot/pgsql/src/backend/parser/gram.y,v 2.252 2001/09/20 14:20:27 petere Exp $
+ *   $Header: /cvsroot/pgsql/src/backend/parser/gram.y,v 2.253 2001/09/23 03:39:01 momjian Exp $
  *
  * HISTORY
  *   AUTHOR            DATE            MAJOR EVENT
@@ -3587,8 +3587,8 @@ OptUseOp:  USING all_Op                           { $$ = $2; }
        ;
 
 
-select_limit:  LIMIT select_limit_value ',' select_offset_value
-           { $$ = makeList2($4, $2); }
+select_limit:  LIMIT select_offset_value ',' select_limit_value
+           { $$ = makeList2($2, $4); }
        | LIMIT select_limit_value OFFSET select_offset_value
            { $$ = makeList2($4, $2); }
        | LIMIT select_limit_value