Re: keyword list/ecpg - Mailing list pgsql-hackers

From Tom Lane
Subject Re: keyword list/ecpg
Date
Msg-id 24276.1212589279@sss.pgh.pa.us
Whole thread Raw
In response to Re: keyword list/ecpg  (Michael Meskes <meskes@postgresql.org>)
Responses Re: keyword list/ecpg  (Michael Meskes <meskes@postgresql.org>)
List pgsql-hackers
Michael Meskes <meskes@postgresql.org> writes:
> On Tue, May 27, 2008 at 09:44:02AM -0400, Tom Lane wrote:
>> If we were going to do that, I'd want it to go all the way and somehow
>> generate the common parts of the two .y files from a single source.

> Any idea how to make this happen? We could of course do it with a lot of
> ifdef like sequences:

> rule {
> IF ECPGCOMPILE
>     ecpg stuff
> ELSE
>     backend stuff
> ENDIF
> }

> Would you go into this direction?

Ugh :-(.

I have not spent much time looking at the ecpg grammar, so feel free to
laugh this off, but I had the impression that all the rules derived from
the backend grammar have boilerplate action sections (ie, just join the
strings together).  So I was hoping that we could leave the backend's
.y file more or less as-is, and write a perl script that would go
through it and replace each { ... } action with a suitable cat_str call,
which it could build on-the-fly by counting the number of rule tokens.
Then combine that output with the ecpg-specific rules taken from a
separate source file.  Obviously there would have to be a few small
kluges, but an #if-like mechanism might suffice for those.  An #if
in every rule is way past my tolerance for ugliness though, especially
when one arm of it is essentially mechanically-generatable code.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Andreas Pflug
Date:
Subject: Re: Overhauling GUCS
Next
From: Aidan Van Dyk
Date:
Subject: Re: Overhauling GUCS