Re: Fix for FETCH FIRST syntax problems - Mailing list pgsql-hackers

From Andrew Gierth
Subject Re: Fix for FETCH FIRST syntax problems
Date
Msg-id 8736yn43ub.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: Fix for FETCH FIRST syntax problems  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:

 Tom> Also, why'd you back off "must write" to "should write" in the docs?
 Tom> This doesn't make the parens any more optional than before.

Currently, the requirement for parens is inconsistent - FETCH FIRST
wants them for absolutely anything that's not a literal constant, but
OFFSET x ROWS allows any c_expr (which covers a whole lot of ground in
addition to the spec's requirements). The docs don't distinguish these
two and just say "must write" parens even though some cases clearly work
without.

(There's also the slight wart that OFFSET -1 ROWS is a syntax error,
whereas the spec defines it as valid syntax but a semantic error. Do we
care?)

With the patch, c_exprs would be accepted without parens, so saying
"must write" parens in the docs clearly isn't entirely accurate. I'm
open to better phrasing.

I found some more warts: OFFSET +1 ROWS isn't accepted (but should be),
and FETCH FIRST 10000000000 ROWS ONLY fails on 32bit and Windows builds.
The patch as posted fixes the second of those but makes FETCH FIRST +1
fail instead; I'm working on that.

-- 
Andrew (irc:RhodiumToad)


pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Fix some error handling for read() and errno
Next
From: Andrew Gierth
Date:
Subject: Re: Fix for FETCH FIRST syntax problems