Michael Meskes <meskes@postgreSQL.org> writes:
> I've been send a patch to the parser that changes the FETCH statement to not
> accept an empty portal name anymore and and allows FETCH without IN/FROM.
> First of all I really like to add this to ECPG since the different FETCH
> syntax is a major compatibility problem. But I do not like to have ECPG's
> parser accept the statement while the backend does not. Since this is not a
> standard feature I wonder what others think about it.
It looks to me like the backend grammar *does* accept FETCH without
IN/FROM cursor. Which seems pretty bizarre --- I don't understand how
it makes sense to omit a cursor name from FETCH.
Looking at the SQL92 spec, it seems we are mighty far away from any
defensible reading of the spec :-(. The spec says
<fetch statement> ::= FETCH [ [ <fetch orientation> ] FROM ] <cursor name> INTO
<fetchtarget list>
<fetch orientation> ::= NEXT | PRIOR | FIRST | LAST
| { ABSOLUTE | RELATIVE } <simple value specification>
<fetch target list> ::= <target specification> [ { <comma> <target specification> }... ]
whereas gram.y has
FetchStmt: FETCH opt_direction fetch_how_many opt_portal_name | MOVE opt_direction fetch_how_many
opt_portal_name ;
opt_direction: FORWARD | BACKWARD | RELATIVE | ABSOLUTE | /*EMPTY*/ ;
fetch_how_many: Iconst | '-' Iconst | ALL | NEXT | PRIOR | /*EMPTY*/ ;
opt_portal_name: IN name | FROM name | /*EMPTY*/ ;
Are we compatible with anything at all???
regards, tom lane
