From: | Boszormenyi Zoltan <zb(at)cybertec(dot)at> |
---|---|
To: | Michael Meskes <meskes(at)postgresql(dot)org> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, hs(at)cybertec(dot)at |
Subject: | Re: Split-up ECPG patches |
Date: | 2009-08-08 17:55:18 |
Message-ID: | 4A7DBC06.1080103@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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/
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-08-08 18:10:12 | Re: Split-up ECPG patches |
Previous Message | Alvaro Herrera | 2009-08-08 17:50:17 | Re: contrib/pg_freespacemap |