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: meskes@jabber.org
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!
