Michael Meskes írta: > On Sat, Aug 08, 2009 at 05:48:57PM +0200, Boszormenyi Zoltan wrote: > >> ... >> "/usr/bin/perl" ./parse.pl . < ../../../../src/backend/parser/gram.y > >> preproc.y >> /usr/bin/bison -d -o preproc.c preproc.y >> preproc.y: conflicts: 2 shift/reduce >> preproc.y: expected 0 shift/reduce conflicts >> make[4]: *** [preproc.c] Error 1 >> make[4]: Leaving directory >> `/home/zozo/Schönig-számlák/leoni/2/pgsql/src/interfaces/ecpg/preproc' >> ... >> > > Right, I missed this one. But it's ecpg specific and should not be fixed by > changing gram.y.
Debatable. :-) > 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. With the proposed core grammar change, the feature where you can pass the number of records to be fetched in a string variable can be kept. > Also keep in mind that a > fetch statement without from/in is an addition on top of the standard. It seems to be Informix-specific, I just looked it up in their guide_to_sql_syntax.pdf. > I'm not > sure if any other dbms still allows this construct, so we might we well remove > it for 8.5. Or move it to a special compatibility mode. > How would you do that? With a completely different parser for Informix-compatibility? It would reduce maintainability. Or does bison allow conditionally enabled rules somehow? It sure would come in handy in this case. 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