Re: [HACKERS] parser changes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: PostgreSQL Hacker <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: [HACKERS] parser changes
Date: 2000-02-16 06:26:22
Message-ID: 1845.950682382@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2000-02-16 06:44:15 Re: [HACKERS] IBM sues Informix over DB patents
Previous Message Thomas Lockhart 2000-02-16 06:10:29 Re: [HACKERS] Almost there on column aliases