| From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: SQL:2008 LIMIT/OFFSET |
| Date: | 2008-10-20 15:08:48 |
| Message-ID: | 48FC9F00.8000907@gmx.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> SQL:2008 specifies the following syntax for what we have so far called
>> LIMIT and OFFSET
>> SELECT ... [ ORDER BY ... ]
>> OFFSET num {ROW|ROWS} FETCH {FIRST|NEXT} [num] {ROW|ROWS} ONLY
>
> What does the "NEXT" option mean?
FIRST and NEXT mean exactly the same, namely nothing.
> BTW, I think it's a bad idea to assign made-up parse locations, as
> you did here:
>
>> + | /*EMPTY*/ { $$ = makeIntConst(1, @$); }
>
> Just use -1.
Hmm, @$ is the location of the complete rule, so it should point to the
"empty" spot in theory. Or am I misunderstanding something?
It's hard to simulate an error with this of course.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2008-10-20 15:11:59 | Re: Index use during Hot Standby |
| Previous Message | Simon Riggs | 2008-10-20 14:56:25 | Re: Block level concurrency during recovery |