Re: automatic parser generation for ecpg - Mailing list pgsql-hackers

From Tom Lane
Subject Re: automatic parser generation for ecpg
Date
Msg-id 18633.1224594613@sss.pgh.pa.us
Whole thread Raw
In response to Re: automatic parser generation for ecpg  (Mike Aubury <mike.aubury@aubit.com>)
Responses Re: automatic parser generation for ecpg
List pgsql-hackers
Mike Aubury <mike.aubury@aubit.com> writes:
> In reality - it doesn't look too disimilar from the awk original. I didn't 
> appreciate that we'd probably need to keep 2 versions (one for unix and one 
> for windows). In that case - I'd argue that we only need to "maintain" one 
> and regenerate the other when required. Provided they both work the same, I'd 
> say it doesn't matter what the perl one looked like, because thats not the 
> one that'd be maintained :-)

That'd only be acceptable if the code conversion were fully automatic
--- given your reference to "tweaks" I wasn't sure if that could be the
case.

> Personally - I'd be tempted to keep this as a background process for
> the ecpg maintiner anyway rather than a normal end user.

While we could approach it that way, it doesn't really meet all the
goals I was hoping for.  The current process is unsatisfactory for at
least two reasons above and beyond "Michael has to do a lot of
gruntwork":

* People hacking on the core grammar might break ecpg without realizing
it.  They need short-term feedback from the standard build process,
or at the worst from the standard buildfarm checks.

* For the last little while, changing the core keyword set breaks ecpg
completely, which means we have the worst of all possible worlds: core
modifiers have to hack ecpg to get it to compile, and then Michael has
to do more work to get it to actually work right.

I've been willing to put up with the second problem because I expected
the ecpg grammar build process to become fully automatic soon.  If that
doesn't happen then I'm going to be lobbying to revert the change that
made ecpg depend directly on the core keyword set.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_stat_statements in core
Next
From: Magnus Hagander
Date:
Subject: Re: minimal update