Re: [HACKERS] parser changes

Michael Meskes <meskes(at)postgreSQL(dot)org> writes:
>> It seems to me that this whole business of tracking a hand-maintained
>> modified copy of gram.y is wrong. There ought to be a way for ecpg to
>> just incorporate the backend grammar by reference, plus a few rules
>> on top for ecpg-specific constructs.

> I would love this. But frankly I don't see how we can accomblish this. After
> all ECPG has to print out the statment word by word while the backend puts
> it into internal structure.
> Any ideas anyone?

Ah, your point is that the actions have to be different even if the
yacc grammar is the same. Hmm. A few ideas off the top of the head:

1. Create a tool that strips the backend's actions out of gram.y
and inserts ecpg's actions to produce a gram.y file for ecpg, all
automatically. This could probably be done with a perl script,
although it might require tweaking gram.y to have a more uniform
layout convention for its actions. (You'd also need to figure out
how to identify which ecpg action code snippet to insert for each
rule, which is not so easy.)

2. Revise gram.y so that all it does is call functions that are
defined in another file; then ecpg and backend use the same gram.y,
but link it to different sets of action subroutines.

3. Use the backend's gram.y as it stands, and rewrite ecpg to
reverse-list the statements from the parsetree constructed by the
grammar. (You could steal most of the logic from ruleutils.c.)

Aside from the work involved, the major problem with any of these
approaches is that practically any change in or around the backend's
gram.y would instantly break ecpg; backend and ecpg source would
have to be maintained in strict synchrony or the system wouldn't
even compile. Perhaps that would be good discipline ;-) but I doubt
there will be much enthusiasm for it among the backend developers.
The current way at least allows ecpg development to proceed at its
own schedule.

Still, it seems like you might want to think about building some
kind of tool to help you with keeping the files in sync. For example,
it'd probably be easier to diff ecpg and backend grammar files if
you made a script that just strips out the action parts.

regards, tom lane