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  (Michael Meskes <meskes@postgresql.org>)
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:

Previous
From: Tom Lane
Date:
Subject: Re: Alpha releases: How to tag
Next
From: Pavel Stehule
Date:
Subject: Re: mixed, named notation support