Boszormenyi Zoltan <zb@cybertec.at> writes:
> Tom Lane �rta:
>> I'd look at requiring from_in as being the least-bad alternative.
> Hm. "FETCH FORWARD variable" can only be a rowcount var
> only if there's something afterwards, no? With the proposed
> change in fetch_direction (moving FORWARD and BACKWARD
> without the rowcount upper to the parent rules) now the parser is
> able to look behind "FORWARD variable"...
The fundamental reason that there's a problem here is that ecpg has
decided to accept a syntax that the backend doesn't (ie, FETCH with a
fetch direction but no FROM/IN). I think that that's basically a bad
idea: it's not helpful to users to be inconsistent, and it requires ugly
hacks in ecpg, and now ugly hacks in the core grammar as well. We
should resolve it either by taking out that syntax from ecpg, or by
making the backend accept it too. Not by uglifying the grammars some
more in order to keep them inconsistent.
If we were going to allow it in the core, I think moving the cursor
name into the fetch_direction production might work, ie, change
fetch_direction to fetch_args and make it cover everything that
FETCH and MOVE share. Probably from_in could become opt_from_in,
since the alternatives for it are fully reserved words already, and we
wouldn't need to double up any of the fetch_direction productions.
regards, tom lane