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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: BUG #5889: "Intersects" for polygons broken
Следующее
От: Tom Lane
Дата:
Сообщение: Re: BUG #5924: bug or feature?