Re: Split-up ECPG patches - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Split-up ECPG patches
Date
Msg-id 26629.1249755012@sss.pgh.pa.us
Whole thread Raw
In response to Re: Split-up ECPG patches  (Boszormenyi Zoltan <zb@cybertec.at>)
Responses Re: Split-up ECPG patches  (Boszormenyi Zoltan <zb@cybertec.at>)
List pgsql-hackers
Boszormenyi Zoltan <zb@cybertec.at> writes:
> Michael Meskes írta:
>> The problem is that SignedIconst might be a char variable,
>> too. So how shall the parser know whether str in "FETCH BACKWARD :str" carries
>> the number of records to move backwards ot the cursor name.

> This was the problem, yes.

>> A possible solution
>> would be to force a numeric variable for numeric data.

> By which you would remove a feature.

If you ask me, the real problem here is the productions ecpg adds to
make "from_in" optional.  If a CVARIABLE can be either a fetch_count
or a cursor_name, then removing from_in makes the grammar fundamentally
ambiguous; no amount of rearrangement will fix that.

I'd look at requiring from_in as being the least-bad alternative.  What
I now see is that Zoltan's previous patch is removing a different subset
of the possible parses (and has to modify the core grammar in order to
be able to do that); to wit, it's arbitrarily deciding that "FETCH
FORWARD variable" must be a cursor name variable and not a row count
variable.  That strikes me as a non-orthogonal, error-prone kluge.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Boszormenyi Zoltan
Date:
Subject: Re: Split-up ECPG patches
Next
From: Boszormenyi Zoltan
Date:
Subject: Re: Split-up ECPG patches