From: | Korry Douglas <korry(dot)douglas(at)enterprisedb(dot)com> |
---|---|
To: | Michael Meskes <meskes(at)postgresql(dot)org> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Zoltan Boszormenyi <zb(at)cybertec(dot)at>, PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: ecpg preprocessor regression in 9.0 |
Date: | 2010-11-02 17:51:29 |
Message-ID: | 2EE12379-4A35-40A8-977B-0CC43B8A7FEB@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
>> 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?
Why not a function instead of a macro? You can set a breakpoint on a
function if you need to debug.
It seems unlikely that you would every see any measurable performance
gain by writing a macro instead of a function.
-- Korry
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2010-11-02 19:34:40 | Re: ecpg preprocessor regression in 9.0 |
Previous Message | Michael Meskes | 2010-11-02 17:39:13 | Re: ecpg preprocessor regression in 9.0 |