Re: ecpg preprocessor regression in 9.0
От | Heikki Linnakangas |
---|---|
Тема | Re: ecpg preprocessor regression in 9.0 |
Дата | |
Msg-id | 4D7A408C.5000800@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: ecpg preprocessor regression in 9.0 (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Список | pgsql-bugs |
On 01.11.2010 15:47, Heikki Linnakangas wrote: > On 01.11.2010 15:31, Heikki Linnakangas wrote: >> This used to work in the PostgreSQL 8.4 ecpg preprocessor: >> >> EXEC SQL EXECUTE mystmt USING 1.23; >> >> but in 9.0 it throws an error: >> >> floattest.pgc:39: ERROR: variable "1" is not declared >> >> Attached is the full test case, drop it in >> src/interfaces/ecpg/test/preproc and compile. >> >> I bisected the cause to this commit: >> >> commit b2bddc2ff22f0c3d54671e43c67a2563deed7908 >> Author: Michael Meskes <meskes@postgresql.org> >> Date: Thu Apr 1 08:41:01 2010 +0000 >> >> Applied Zoltan's patch to make ecpg spit out warnings if a local >> variable hides a global one with the same name. >> >> I don't immediately see why that's causing it, but it doesn't seem >> intentional. > > 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: > > diff --git a/src/interfaces/ecpg/preproc/type.c > b/src/interfaces/ecpg/preproc/type.c > index cc668a2..a53018b 100644 > --- a/src/interfaces/ecpg/preproc/type.c > +++ b/src/interfaces/ecpg/preproc/type.c > @@ -246,7 +246,7 @@ ECPGdump_a_type(FILE *o, const char *name, struct > ECPGtype * type, > struct variable *var; > > if (type->type != ECPGt_descriptor && type->type != ECPGt_sqlda && > - type->type != ECPGt_char_variable && > + type->type != ECPGt_char_variable && type->type != ECPGt_const && > brace_level >= 0) > { > char *str; > > 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. This really needs to be fixed, so I just committed the above patch. The code needs some love, it took me a while to realize that find_variable() modifies its argument, for example, which explains the strdups() in ECPGdump_a_type(). And I wonder why we bother to put constants to the global all_variables list at all. And I'm not sure the above type-checks still cover everything. But at least the immediate bug has now been fixed. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-bugs по дате отправления: