From: | Luke McFarlane <luke(at)fisheye(dot)com(dot)au> |
---|---|
To: | Michael Meskes <meskes(at)postgresql(dot)org> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: ecpg -D SYMBOL |
Date: | 2004-07-23 05:49:30 |
Message-ID: | 4100A6EA.7050803@fisheye.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Defining things twice - once in 'SQL' space and once in 'C' space is
something I struggled with when using Informix ESQL/C. I like the idea
of having it apply to both.
Although if you are to support INFORMIX or INFORMIX_SE mode in ecpg you
will need limit it to 'SQL' space (for these modes anyway).
Michael Meskes wrote:
>On Tue, Jul 06, 2004 at 03:49:14PM +1000, Luke McFarlane wrote:
>
>
>>When defining a symbol on the command line with ecpg -D SYMBOL the ecpg
>>preprocessor will replace that symbol with empty space in 'C' program
>>space rather than limiting it to 'SQL' program space.
>>
>>
>
>This indeed is a bug, but ecpg has never been designed to limit symbols
>to SQL space. You're absolutely right that it should not use empty
>space. I just fixed that in CVS. Now it correctly uses "1".
>
>
>
>>It shouldn't touch anything outside EXEC SQL.
>>
>>
>
>Why? That means you have to define most things twice.
>
>
>
>>Also, if you try to fool ecpg by compiling with ecpg -D SYMBOL=SYMBOL it
>>will sit in an infinite loop gobbling as much virtual memory as it sees fit.
>>
>>
>
>Ah yes, another bug.
>
>I just committed a fix for this as well.
>
>All fixes went into HEAD and 7.4.
>
>Michael
>
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Markus Bertheau | 2004-07-23 08:05:29 | Re: BUG #1197: index bug |
Previous Message | Frank van Vugt | 2004-07-22 14:18:31 | Re: adding a primary key column to a temporary table fails |