Thread: parser changes
We have to make sure this time all parser changes make it into ecpg's parser as well. Not like 6.5.3 where the backend accepted queries that ecpg didn't. Right now I'm very busy though, so please bear with me if I need a little more time. I will try to keep as much up-to-date as possible. Michael -- Michael Meskes | Go SF 49ers! Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire! Tel.: (+49) 2431/72651 | Use Debian GNU/Linux! Email: Michael@Fam-Meskes.De | Use PostgreSQL!
> ... this time all parser changes make it into ecpg's parser
Do you have a pretty good way to track changes in gram.y? Let me know
if you want some help (though I won't be able to for a week or so).
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
> > ... this time all parser changes make it into ecpg's parser > > Do you have a pretty good way to track changes in gram.y? Let me know > if you want some help (though I won't be able to for a week or so). I told him to keep a copy of the gram.y he uses, and merge changes from the current version against the copy he has that matched the current ecpg. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>>>> ... this time all parser changes make it into ecpg's parser
>>
>> Do you have a pretty good way to track changes in gram.y? Let me know
>> if you want some help (though I won't be able to for a week or so).
> I told him to keep a copy of the gram.y he uses, and merge changes from
> the current version against the copy he has that matched the current
> ecpg.
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 will freely admit that I have no idea what's standing in the way of
that ... but it seems like we ought to try to work towards the goal
of not having a synchronization problem in the first place, rather
than spending effort on minimizing the synchronization error. Perhaps
that means tweaking or subdividing the backend grammar, but if so it'd
be effort well spent.
It's probably too late to do anything in this line for 7.0, but
I suggest we think about it for future releases.
regards, tom lane
On Wed, Feb 16, 2000 at 01:26:22AM -0500, Tom Lane wrote: > >> Do you have a pretty good way to track changes in gram.y? Let me know > >> if you want some help (though I won't be able to for a week or so). Right now I'm up-to-date. But I have yet to finish my own todo for 7.0. > > I told him to keep a copy of the gram.y he uses, and merge changes from > > the current version against the copy he has that matched the current > > ecpg. That's exactly how I do it. I run diff from time to tim and add the changes to my version by hand. > 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. > It's probably too late to do anything in this line for 7.0, but > I suggest we think about it for future releases. Any ideas anyone? Michael -- Michael Meskes | Go SF 49ers! Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire! Tel.: (+49) 2431/72651 | Use Debian GNU/Linux! Email: Michael@Fam-Meskes.De | Use PostgreSQL!
Michael Meskes <meskes@postgreSQL.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
> 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. Let me know if you need help with that. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Wed, Feb 16, 2000 at 10:07:06AM -0500, Tom Lane wrote: > ... > 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 That means everyone who changes gram.y nowadays would then have to change the corresponding ecpg function as well. Nice idea. :-) > there will be much enthusiasm for it among the backend developers. I'm afraid you're right on this one. > 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. It's not that difficult to read and apply a context diff by hand. After all the changes are mostly moderately. michael -- Michael Meskes | Go SF 49ers! Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire! Tel.: (+49) 2431/72651 | Use Debian GNU/Linux! Email: Michael@Fam-Meskes.De | Use PostgreSQL!