Re-enable error for "SELECT ... OFFSET -1".
authorTom Lane <tgl@sss.pgh.pa.us>
Tue, 22 Jul 2014 17:30:01 +0000 (13:30 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Tue, 22 Jul 2014 17:30:09 +0000 (13:30 -0400)
The executor has thrown errors for negative OFFSET values since 8.4 (see
commit bfce56eea45b1369b7bb2150a150d1ac109f5073), but in a moment of brain
fade I taught the planner that OFFSET with a constant negative value was a
no-op (commit 1a1832eb085e5bca198735e5d0e766a3cb61b8fc).  Reinstate the
former behavior by only discarding OFFSET with a value of exactly 0.  In
passing, adjust a planner comment that referenced the ancient behavior.

Back-patch to 9.3 where the mistake was introduced.

src/backend/optimizer/plan/planner.c

index 0f1e2e46802613e960e64956ffe934d80468e681..8e3a9068f1f725cb0b12492460b48e78869ac2ad 100644 (file)
@@ -2334,7 +2334,7 @@ preprocess_limit(PlannerInfo *root, double tuple_fraction,
            {
                *offset_est = DatumGetInt64(((Const *) est)->constvalue);
                if (*offset_est < 0)
-                   *offset_est = 0;    /* less than 0 is same as 0 */
+                   *offset_est = 0;    /* treat as not present */
            }
        }
        else
@@ -2495,9 +2495,8 @@ limit_needed(Query *parse)
            {
                int64       offset = DatumGetInt64(((Const *) node)->constvalue);
 
-               /* Executor would treat less-than-zero same as zero */
-               if (offset > 0)
-                   return true;    /* OFFSET with a positive value */
+               if (offset != 0)
+                   return true;    /* OFFSET with a nonzero value */
            }
        }
        else