Re: Split-up ECPG patches - Mailing list pgsql-hackers
From | Boszormenyi Zoltan |
---|---|
Subject | Re: Split-up ECPG patches |
Date | |
Msg-id | 4A7DBC06.1080103@cybertec.at Whole thread Raw |
In response to | Re: Split-up ECPG patches (Michael Meskes <meskes@postgresql.org>) |
List | pgsql-hackers |
Michael Meskes írta: > On Sat, Aug 08, 2009 at 07:21:59PM +0200, Boszormenyi Zoltan wrote: > >>> 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. >> > > Somehow I doubt this. Yes, your patch originally didn't come with a > shift/reduce problem, but I cannot see how this solved this. The same rule > still has the same problem. > Err, no. E.g. if the whole statement is FETCH BACKWARD cursor_name then it can only carry a cursor name, as always did. No matter if cursor_name is now a static or dynamic name. The problem is with the original factorization of "fetch_direction", now with dynamic cursor name the grammar cannot decide between "FETCH BACKWARD :no_of_rec ..." and "FETCH BACKWARD :cursor" Same with the FORWARD rule. And _that_ can be solved by decreasing factorization, i.e. pulling FORWARD and BACKWARD up into the FetchStmt rule in the core grammar. >> It seems to be Informix-specific, I just looked it up in >> their guide_to_sql_syntax.pdf. >> > > The questin is, does Oracle so somthing similar? > No idea. I can look up though. >>> 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? >> > > No. > > >> It would reduce maintainability. Or does bison >> allow conditionally enabled rules somehow? >> It sure would come in handy in this case. >> > > No. You have to code around it. What I meant was, that other dbms should have > the same problem. So they solved it one way or the other. And we could create > both solutions just depending on the mode we're in. Informix e.g. doesn't seem > to allow a variable to carry the number of records. Heck, I don't even see > FORWARD/BACKWARD. A number is only given in ABSOLUTE and RELATIVE but no > variable. > > Michael > -- 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/
pgsql-hackers by date: