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:

Previous
From: Alvaro Herrera
Date:
Subject: Re: contrib/pg_freespacemap
Next
From: Tom Lane
Date:
Subject: Re: Split-up ECPG patches