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 <mes...@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

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Reply via email to