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