From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Meskes <meskes(at)postgresql(dot)org> |
Cc: | PostgreSQL Hacker <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: keyword list/ecpg |
Date: | 2008-06-04 14:21:19 |
Message-ID: | 24276.1212589279@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Michael Meskes <meskes(at)postgresql(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Aidan Van Dyk | 2008-06-04 14:35:49 | Re: Overhauling GUCS |
Previous Message | Andreas Pflug | 2008-06-04 14:19:47 | Re: Overhauling GUCS |