Boszormenyi Zoltan írta:
> Tom Lane írta:
>
>> I wrote:
>>
>>
>>> 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.
>>>
>>>
>> On looking a bit closer at this: I think the reason the core grammar
>> requires FROM/IN after fetch_direction is to leave the door open for
>> someday generalizing the fetch count to be an expression, not just an
>> integer constant. If we made FROM/IN optional, then doing that would
>> require some ugly syntax hack or other, such as requiring parentheses
>> around nontrivial expressions. So I'd like to see an actual case made
>> that there's a strong reason for not requiring FROM/IN in ecpg.
>>
>> regards, tom lane
>>
>>
>
> The only reason is I think was the Informix-compatible mode.
> I don't know if it's strong enough, though.
>
I am looking at the original gram.y and there's a special cased
"optional FROM/IN" case already for FETCH and MOVE:
"FETCH name" and "MOVE name". Which can be seen
as optional FORWARD (already in fetch_direction, as its
first rule) and optional FROM/IN.
> Best regards,
> Zoltán Böszörményi
>
>
--
Bible has answers for everything. Proof:
"But let your communication be, Yea, yea; Nay, nay: for whatsoever is more
than these cometh of evil." (Matthew 5:37) - basics of digital technology.
"May your kingdom come" - superficial description of plate tectonics
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
http://www.postgresql.at/
