Re: keyword list/ecpg

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

In response to

Responses

Browse pgsql-hackers by date

  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