From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Michael Meskes <meskes(at)postgresql(dot)org> |
Cc: | Zoltan Boszormenyi <zb(at)cybertec(dot)at>, PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org>, Korry Douglas <korry(dot)douglas(at)enterprisedb(dot)com> |
Subject: | Re: ecpg preprocessor regression in 9.0 |
Date: | 2010-11-02 19:34:40 |
Message-ID: | 4CD067D0.6000900@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On 02.11.2010 19:39, Michael Meskes wrote:
> On Mon, Nov 01, 2010 at 03:47:04PM +0200, Heikki Linnakangas wrote:
>> On closer look, it's quite obvious: the code added to
>> ECPGdump_a_type thinks that ECPGt_const is a variable type, and
>> tries to look up the variable. The straightforward fix is this:
>> ...
>> But I wonder if there is a better way to identify variable-kind of
>> ECPGttypes than list the ones that are not. There's some special
>> ECPGttypes still missing from the above if-test, like
>> ECPGt_NO_INDICATOR, but I'm not sure if they can ever be passed to
>> ECPGdump_a_type. Seems a bit fragile anyway.
>
> I agree. How about adding a macro definition explicitely checking for the real
> variable types?
You'd still have to list them all in the macro, but it would definitely
be better. The list would then be closer to the enums, in the same
header file, making it easier to remember to keep it up-to-date.
(Korry's suggestion of making it a function instead of a macro would not
have that advantage).
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Korry Douglas | 2010-11-02 21:20:49 | Re: ecpg preprocessor regression in 9.0 |
Previous Message | Korry Douglas | 2010-11-02 17:51:29 | Re: ecpg preprocessor regression in 9.0 |