From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SQL:2008 LIMIT/OFFSET |
Date: | 2008-10-20 12:46:07 |
Message-ID: | 27312.1224506767@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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? I'm a bit worried that this isn't
actually quite equivalent to LIMIT.
> If we want to avoid reshuffling the expression syntax (always good to
> avoid) and avoid making ROWS reserved, we need to make some arbitrary
> restrictions on what kinds of expressions can be used in these clauses.
This syntax seems sufficiently brain-dead that only standards-compliance
fanatics would use it. Accordingly, limiting it to match the letter
of the standard (literals only) is probably sufficient.
BTW, I think it's a bad idea to assign made-up parse locations, as
you did here:
> + | /*EMPTY*/ { $$ = makeIntConst(1, @$); }
Just use -1.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2008-10-20 12:50:12 | SSL cleanups/hostname verification |
Previous Message | Magnus Hagander | 2008-10-20 12:43:50 | Re: contrib/pg_stat_statements |