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. > 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? > > 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 -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo/Skype: michaelmeskes, Jabber: mes...@jabber.org Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
