Another bug with parse statements on - Mailing list pgsql-odbc

From Andrea Aime
Subject Another bug with parse statements on
Date
Msg-id 3AE01482.61DB17F7@comune.modena.it
Whole thread Raw
List pgsql-odbc
Hi everybody,
I've just come up with another bug... my last solution was to
apply my tiny bug fix on searchColInfo and keep "parse statements" = 1
Unfortunately this breaks another query, I think because the parser
has some problem with the "as" keyword... With "parse statements" = 1
the following query, issued from VB (using ADO 2.6), fails:

'SELECT min(classe) as minimo, max(classe) as massimo
FROM tav974'
(
 is a carriage return...)

I have found a quick fix, but it may work only in my environment.
1) Set "parse statements" = 0
2) Modify every occurence of:

if (globals.parse && stmt->statement_type == STMT_TYPE_SELECT)

into

if ((globals.parse || stmt->prepare) && stmt->statement_type ==
STMT_TYPE_SELECT)

in results.c.

This forces parsing on every prepared statement but avoids it on every
other
statement. Now my programs are working, but if something would issue a
prepared
statement like:

SELECT min(classe) as minimo, max(classe) as massimo
FROM tav974
where dummycol=?

the driver would fail. I have a mylog file with all the messages that
relates
to the mentioned bug, if you want I can send it to you (10kb if
compressed with
winzip). Sorry, but I have no time now to track down also this one...
maybe
it's stuff for someone more experienced than me.
Regards
Andrea Aime

pgsql-odbc by date:

Previous
From: Hiroshi Inoue
Date:
Subject: Re: Driver patch
Next
From: Dmitry Seleznev
Date:
Subject: ...