Re: [HACKERS] parser changes - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] parser changes
Date
Msg-id 1845.950682382@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] parser changes  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: [HACKERS] parser changes
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Thomas Lockhart
Date:
Subject: Re: [HACKERS] Almost there on column aliases
Next
From: Hannu Krosing
Date:
Subject: Re: [HACKERS] IBM sues Informix over DB patents