Re: BUG #6315: FETCH NEXT :next ROWS ONLY fails - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #6315: FETCH NEXT :next ROWS ONLY fails
Date
Msg-id 18845.1322777164@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #6315: FETCH NEXT :next ROWS ONLY fails  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-bugs
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Excerpts from Tom Lane's message of jue dic 01 18:32:58 -0300 2011:
>> Well, actually it is supported, but you missed the fine print where it
>> says that you have to add parentheses if the offset or count isn't a
>> simple integer constant.  I'll apply a patch to make that a bit more
>> obvious.

> Hmm, it works with parens only in the "fetch next" clause, they don't
> seem necessary in the limit.  FWIW.

ITYM "offset"?  You do need the parens if you want to spell it
SQL:2008's way, with the ROW/ROWS noise word.

regression=# select * from int8_tbl offset 2+2;
        q1        |        q2
------------------+-------------------
 4567890123456789 | -4567890123456789
(1 row)

regression=# select * from int8_tbl offset 2+2 rows;
ERROR:  syntax error at or near "rows"
LINE 1: select * from int8_tbl offset 2+2 rows;
                                          ^
regression=# select * from int8_tbl offset (2+2) rows;
        q1        |        q2
------------------+-------------------
 4567890123456789 | -4567890123456789
(1 row)

The comment in gram.y says there are parsing conflicts if we try to not
require the parens, and that SQL:2008 doesn't actually require anything
beyond a simple integer constant here.

            regards, tom lane

pgsql-bugs by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: BUG #6315: FETCH NEXT :next ROWS ONLY fails
Next
From: Bernhard Reutner-Fischer
Date:
Subject: Re: BUG #6315: FETCH NEXT :next ROWS ONLY fails