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

From Boszormenyi Zoltan
Subject Re: Split-up ECPG patches
Date
Msg-id 4A7EF0D0.6010403@cybertec.at
Whole thread Raw
In response to Re: Split-up ECPG patches  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Split-up ECPG patches  (Boszormenyi Zoltan <zb@cybertec.at>)
List pgsql-hackers
Tom Lane írta:
> Boszormenyi Zoltan <zb@cybertec.at> writes:
>   
>> Tom Lane írta:
>>     
>>> I'd look at requiring from_in as being the least-bad alternative.
>>>       
>
>   
>> Hm. "FETCH FORWARD variable" can only be a rowcount var
>> only if there's something afterwards, no? With the proposed
>> change in fetch_direction (moving FORWARD and BACKWARD
>> without the rowcount upper to the parent rules) now the parser is
>> able to look behind "FORWARD variable"...
>>     
>
> The fundamental reason that there's a problem here is that ecpg has
> decided to accept a syntax that the backend doesn't (ie, FETCH with a
> fetch direction but no FROM/IN).  I think that that's basically a bad
> idea: it's not helpful to users to be inconsistent, and it requires ugly
> hacks in ecpg, and now ugly hacks in the core grammar as well.  We
> should resolve it either by taking out that syntax from ecpg, or by
> making the backend accept it too.  Not by uglifying the grammars some
> more in order to keep them inconsistent.
>
> If we were going to allow it in the core, I think moving the cursor
> name into the fetch_direction production might work, ie, change
> fetch_direction to fetch_args and make it cover everything that
> FETCH and MOVE share.  Probably from_in could become opt_from_in,
> since the alternatives for it are fully reserved words already, and we
> wouldn't need to double up any of the fetch_direction productions.
>
>             regards, tom lane
>   

Your guess about making from_in into opt_from_in
seems good, mostly. I tried doing exactly that and simply
adding an empty match into from_in, I got shift/reduce conflicts
only in "opt_from_in cursor_name". So, this rule has to be
unrolled into 3 rules, or keeping a separate "from_in" just for
having a separate "cursor_name" and "from_in cursor_name".
I decided that I use the second method, it's shorter.

Best regards,
Zoltán Böszörményi

-- 
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: Tom Lane
Date:
Subject: Re: a short trip in the wayback machine
Next
From: Tom Lane
Date:
Subject: Re: join removal