Re: Split-up ECPG patches

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/

In response to

Browse pgsql-hackers by date

  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