Tom Lane írta: > Boszormenyi Zoltan <z...@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. >
And maybe, possibly with this change as a start, someday we can support dynamic cursorname in plain SQL, too. DECLARE $1 CURSOR FOR SELECT ... It would be a much cleaner solution in ECPG, too. 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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
