Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

Next:From: Aidan Van DykDate: 2008-06-04 14:35:49
Subject: Re: Overhauling GUCS
Previous:From: Andreas PflugDate: 2008-06-04 14:19:47
Subject: Re: Overhauling GUCS

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group