Tom Lane írta: > Boszormenyi Zoltan <z...@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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
