Re: [HACKERS] FETCH without FROM/IN

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