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).
Sure it would... use a switch statement that explicitly handles each
type and include a default case that throws an error (or assertion).
Of course, you have to run into the code to find out that you forgot
to maintain the classification function. A good C compiler will even
spot the problem if you forget to handle one or more enum values in
the switch statement. A macro offers no assurances at all.
-- Korry
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
