Tom Lane írta:
> Boszormenyi Zoltan <zb@cybertec.at> writes:
>
>> Michael Meskes Ărta:
>>
>>> The problem is that SignedIconst might be a char variable,
>>> too. So how shall the parser know whether str in "FETCH BACKWARD :str" carries
>>> the number of records to move backwards ot the cursor name.
>>>
>
>
>> This was the problem, yes.
>>
>
>
>>> A possible solution
>>> would be to force a numeric variable for numeric data.
>>>
>
>
>> By which you would remove a feature.
>>
>
> If you ask me, the real problem here is the productions ecpg adds to
> make "from_in" optional. If a CVARIABLE can be either a fetch_count
> or a cursor_name, then removing from_in makes the grammar fundamentally
> ambiguous; no amount of rearrangement will fix that.
>
> I'd look at requiring from_in as being the least-bad alternative. What
> I now see is that Zoltan's previous patch is removing a different subset
> of the possible parses (and has to modify the core grammar in order to
> be able to do that); to wit, it's arbitrarily deciding that "FETCH
> FORWARD variable" must be a cursor name variable and not a row count
> variable. That strikes me as a non-orthogonal, error-prone kluge.
>
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"...
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/
