Re: Split-up ECPG patches - Mailing list pgsql-hackers
From | Boszormenyi Zoltan |
---|---|
Subject | Re: Split-up ECPG patches |
Date | |
Msg-id | 4A771772.50509@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
|
List | pgsql-hackers |
Tom Lane írta: > Boszormenyi Zoltan <zb@cybertec.at> writes: > >> new versions attached, updated to apply to the current CVS cleanly. >> > > Why is this messing with the core grammar? > > regards, tom lane > It was explained in earlier mails, let me explain it again but a bit more verbosely. This was the evolution of my approaches adding the dynamic cursorname: At first, I changed ECPG grammar only. This meant adding one new rule for every rule dealing with FETCH or MOVE in the ECPG grammar. It turned out quickly, that these two rules below: FETCH fetch_direction from_in cursor_name ecpg_into MOVE fetch_direction from_in cursor_name created shift/reduce conflicts in fetch_direction. This conflict could have been solved by decreasing factorization of "fetch_direction", pulling "BACKWARD" and "FORWARD" (without the row number indicator) up to the rules using "fetch_direction". Which could be solved by two ways. 1. Leave the original (auto-generated) rules alone and add the new ones together with a new fetch_direction2 rule used by the dynamic cursorname FETCH/MOVE rules. At this point the FETCH/MOVE ruleset was so proliferated that my eyes started aching just by looking at it. And as Michael Meskes said, it was a great step back in the ECPG auto-generated grammar introduced in 8.4. 2. With the first approach being a dead-end, I tried to unify the two ruleset (FETCH/MOVE with and without dynamic cursorname variable). But it only worked if I add these changes: - add the "cursor_name" rule to the main grammar, so it can be picked up by the auto-generated ECPG grammar - "cursor_name" has a new subrule dealing with host variables in ECPG - the above solution for solving the shift/reduce problems in *ECPG*, needed the change in the main grammar, so auto-generationstill works, and both the main grammar and the ECPG grammar are clean. I hope I explained it well, the first approach would have made the autogenerated ECPG grammar very unclean, you would have rejected immediately seeing that proposed. 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: