On Tue, Nov 04, 2008 at 01:03:44PM -0500, Tom Lane wrote:
> I'm quite unhappy with the invasiveness of the proposed gram.y changes.
Keep in mind that this is work in progress. I'm still working on this stuff and
yes, I'm trying to simplify things.
> The @ECPG annotations are bad enough, but why are you changing actual
> productions? I'm not entirely convinced that the backend still parses
> exactly what it did before.
There are essantially two changes (unless I forgot about a third one :-)):
- fetch_count:
I can remove that one easily by including the block on every single production
for fetch. Doesn't look like a problem. This change came from me taking some
stuff from preproc.y to get a working version first before simplifying.
- variable handling:
This creates the most changes. ECPG needs to accept variables at quite some
places where the backend only accepts constants. The easy way (again WIP) is to
add a variable production to each constant rule. However, this obviously
creates conflicts when allowinf Sconst and Iconst for the same non-terminal.
Therefore I added new non-terminals SconstVar and IconstVar that just resolve
to Sconst and Iconst in gram.y. If you have a better idea I'm willing to listen.
> It strikes me that most if not all of the @ECPGINCLUDE annotations ought
> to be unnecessary given that you've carefully identified each chunk of
> ecpg.addons. The substitution script ought to be able to match those
> annotations to the input for itself.
You mean by hard coding the position? Hmm, that's possibly but creates just
another situation where we might need a manual sync. Just take an addition
that's supposed to be added to the second rule for a non-terminal. Now if you
insert something before that second rule, it won't work anymore.
> FWIW, I'm also pretty firmly convinced that awk was the wrong choice for
> implementing this script...
Well, I work with what I have. What language would you prefer? And btw what
makes you so convinced?
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!