Re: [HACKERS] FETCH without FROM/IN

Michael Meskes <meskes(at)postgreSQL(dot)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 <fetch target 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