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!

Tue, 15 Feb 2000 10:53:34 +0100
Michael Meskes <meskes@postgresql.org>
parser changes
> ... 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

Wed, 16 Feb 2000 04:39:54 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: [HACKERS] parser changes
> > ... 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, Pennsylvania 19026

Wed, 16 Feb 2000 00:48:18 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] parser changes
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

Wed, 16 Feb 2000 01:26:22 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] parser changes 
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!

Wed, 16 Feb 2000 08:12:04 +0100
Michael Meskes <meskes@postgreSQL.org>
Re: [HACKERS] parser changes
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

Wed, 16 Feb 2000 10:07:06 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] parser changes 
> 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, Pennsylvania 19026

Wed, 16 Feb 2000 11:03:29 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] parser changes
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!

Wed, 16 Feb 2000 17:34:27 +0100
Michael Meskes <meskes@postgreSQL.org>
Re: [HACKERS] parser changes